Feedback as a Mistaek Limiter
Accelerating learning is not just about accelerating feedback.
We all have more than one customer
Let’s first recognise that — in every piece of work we do — we have more than one customer. We of course have an end customer — the ultimate consumer of what we produce. However, we also have an immediate customer — the next person in the production line who is going to take our output closer towards the end customer.
In the case of a graphic designer, whilst their end customer may be the general public, their immediate customer may be the editor who needs to incorporate their graphic into a pamphlet. They may need to ensure it is the correct dimensions, relevant to the surrounding material and keeps to the same tone as the rest of the pamphlet.
In the case of the developer, whilst their end customer will be the user, their very next customer could be the person who needs to support the software once created and ensure it remains functional and accessible to the users.
We must keep both our intermediate and our end customers happy.
Bring feedback forward to limit the size of mistakes
As humans, mistakes are natural. However, by bringing feedback forward from both our intermediate and end customer, we limit the size of the mistakes we make. We can learn and adapt our behaviour earlier, thereby reducing frustration, waste and rework; and increasing quality and ‘delight’.
“Defects are not free. Somebody makes them, and gets paid for making them.”
— W. Edwards Deming
The value of bringing feedback forward is to reduce the size of mistakes. This principle is at the core of Agile and Lean Startup, and in enabling adaptive organisations.
Feedback is noise if the problem to be solved is not understood
Feedback is rarely in short supply. Often, when asking for feedback from our colleagues, we’ll receive multitudes: “maybe change the colour — blue is nicer”, “have you thought about a serif font, rather than sans serif?”.
Good, actionable feedback from colleagues depends on a shared understanding of the problem to be solved, and understanding measures of success in customers’ terms (e.g.: clarity of writing, intuitiveness of an interface, response time of a piece of software).
I believe I felt this as a young Product Manager. Without a clear understanding of the customer’s problem to be solved, and measures of success in the customers’ terms, it felt impossible to prioritise features to be developed. Even more importantly, I could not decide which features should not be developed. My colleagues’ feedback contradicted with my own thinking, and made it only harder to see the wood for the trees.
We must first know we’ve made a mistake before we can learn
The side-benefit of being clear and explicit on the problem to be solved, and the measures of success in customers’ terms, is that you are now able to be proven wrong. And, by being proven wrong, you unlock the ability to learn.
As that young Product Manager, how could I hope to improve how I prioritise, if I had no established method in the first place? If I had devised and made explicit a prioritisation method — such as prioritising feature development for mobile phones because I think our users are always on the go — I would then have the opportunity for my method to be proven wrong, and improved.
I might subsequently notice my users are never on the go, always accessing our service from their laptop.
Herein lies the foundation for Continuous Process Improvement.
“Without theory, experience has no meaning. Without theory, one has no questions to ask. Hence without theory, there is no learning.”
— W. Edwards Deming
We all have more than one customer: an end customer, the consumer, and an immediate customer, the next person in the production line. By bringing feedback forward from these customers, we limit the size of mistakes — reducing waste, and increasing delight.
Whilst feedback is noise if the problem to be solved is not understood, but we must first know we’ve made a mistake before we can learn.
