More feedback is not “more better”.
Feedback is the lifeblood of software products. Rather than relying on BDUF, we steer our development with feedback as our compass.
I remember learning about Scrum and the agile software development movement. It made so much sense.
Rather than following a plan created when we had the fewest insights, why not react to continuous feedback along the way? We would always know whether we were building the right thing.
That obsession with building the right thing and not just building a thing right has elevated our industry. Say what you want about the flaws of modern-day "Agile", but the paradigm shift from prediction to feedback was nothing short of a Copernican revolution.
Scrum, as a leading methodology, had multiple built-in feedback mechanisms. Retrospectives, sprint demos, and shippable increments all serve that purpose. They are there to capture early and often.
Later, when Product Management ideas started to become mainstream, we saw a second explosion of feedback mechanisms in the shape of product metrics, surveys and user interviews.
All of these tools are great. But as is always the case, there's a caveat.
Feedback isn't free. There's a real cost linked to capturing, handling, and even dismissing it. More feedback is not better.
I remember being a Scrum Master on a project where I rigorously planned sprint demos. Every other week, all the Business people would get together in a meeting room and look at what our team cooked up.
Those demos felt like children showing off their art and craft homework to their teacher. "As you can see, we really did our job."
Most of these demos were met with silent nods. Nobody applauds a team that built what it got paid to build, right?
But at the end of each demo, there was always room for interaction. I made a point of asking for feedback. And when you ask people for feedback, guess what you'll get?
Each of those demos would create a list of unrelated product ideas, prohibitively expensive changes, and proposals that challenged the product's usefulness. At the end of each sprint, we would have a list of honest, well-meaning, and totally useless feedback.
The truth is that we were asking for feedback from the wrong people at the wrong time. There's an art to getting it right.
When it comes to asking for feedback, there are three human quirks to consider.
For every question there is an equal and opposite feedback
Business people and managers love to contribute. When you invite them to a meeting, they'll happily join. People get really excited about building new products! So when somebody sits through a 45-minute show-and-tell of an unfinished product, and you ask them for their opinion, they will feel forced to chip in.
That's the reason why the logo always needs to be bigger! Rather than getting paid to say "dunno, looks good to me", people will feel compelled to give feedback. Any kind of feedback. Anything is better than drawing a blank.
Stakeholders just don't care about work in progress
Stakeholders don't care about unfinished features. If you invite them to show a user interface that's not good enough to go live, they might be occasionally interested. But if you show them this slow progress every other week, they'll get bored. And rightfully so. They don't want the farmer to lecture them on the growth stages of the tomato plant. They want tomatoes.
Feedback comes in three tiers
The point of feedback is to figure out whether we are still building the right thing. But not all feedback is equally valuable. It all depends on the level where we're asking feedback.
On the lowest level, developers capture feedback from their peers. This level answers the question "does the team think we're building the right thing?".
The second layer is stakeholder feedback. It answers the question, "Does the company think we are still building the right thing?"
Both questions are valuable. But if all we collect is team and stakeholder feedback, we are missing out on the real deal: putting it in the hands of the users. Customer feedback is the final and highest tier.
So, armed with these three ideas, it becomes clear what we need to do.
To capture developer-tier feedback, we rely on code reviews, pair programming, or dev demos. Monotasking is a great way to share knowledge and continuously capture reactions. At this level, more is better.
To capture stakeholder-level feedback efficiently, we need to drive down the frequency. This goes against the "more feedback is more better" mentality that's so common these days. We don't want to show and tell every user story to a committee of stakeholders. Such a snoozefest only leads to inane comments.
Instead, we want to gather input on big features when they’re around 50% done. That's big enough to get valuable feedback while being small enough to steer the ship if discrepancies are discovered.
Big review meetings are OK, but a great alternative is to record the demo and share it asynchronously. That way, every stakeholder is involved, but nobody is put on the spot to blurt out feedback in real-time. They watch the video, mull it over, and send their feedback only when necessary.
Finally, there's the top-tier level of user feedback. This is where those Product Management tools shine. Release early and often and add those metrics to make informed decisions about how a feature is used. This is the level that matters and where most of our attention should be spent.
Too many teams use feedback as a crutch. They ask permission from their stakeholders, who, in turn, feel compelled to say something inspiring. That leads to a large backlog and a small number of actual releases. It’s product procrastination in its purest form.
When we capture too much feedback too often, we postpone delivery and can’t capture top-tier user feedback. And when we capture feedback but ignore it in order to ship, we are alienating our stakeholders. What’s the point if your opinions get ignored anyway?
That’s the cost of getting too much feedback from the wrong people at the wrong time: we damage the relationship with our stakeholders and fail to capture the most valuable feedback of all: our user’s.