Talking about “quality”…

Vinay Mohanty
Aug 24, 2017 · 3 min read

These days I explain quality to teams (engineering / executives /designers / product managers) like this.

“ Quality by itself is not the goal. The goal is learning fast and iterating through what works and what doesn’t. Like for like, the product that iterates faster from an initial idea to an execution that works at scale — wins”

However, without a certain level of quality across the board, and the iteration experiment you are launching being near perfect & doing a flawless execution in your core assumption — you will not know why things failed.

You can ignore quality (quality in design, scope, engineering) and launch your experiment fast. But it do it at your own risk.

In a muddied experiment with poor quality , it will be difficult to fulfil your objective of learning. Everyone will have mixed opinions and readings of why things failed. Was it bad scoping, too many features, bad UX, bugs, performance & speed , copy or something else ? And your product will get stuck in a zombie land of not knowing what to do next.

And then…… you will have to do some fire-fighting and buy time for more user-research or qualitative testing to separate concept, UX failure from bugs & performance. And after that ….. you will get into circular debates on should you spend more time perfecting things or should you move to next idea ? Meanwhile someone will blame all this on engineering, someone else will say it was bad UX or bad scope or delays that caused it. Slowly, distrust will creep in . The project managers and daily meetings start with reports on everything and conversations on hitting dates etc.

In such situations, everything is late and nothing is ever complete and the organisation starts to feel slow.

I have seen these situations happen over and over again in companies and teams of all sizes. There is no silver bullet here. Often quality is a culture, and a way of thinking. Its not just about not-having-bugs or having a QA department or doing TDD or automation. Those things definitely help, but by themselves don’t bring about a culture of quality in the team. For example — the core reason we automate is so that we can go fast and not worry about breaking something fundamental while we try out a new idea in a separate part of the product.

So, quality starts with thinking lean, thinking true — agile and thinking about focusing on learning cleanly from product iterations. Trying to spend the just enough amount of upfront time and minimising waste that comes from muddied experiments.

It starts with following the cupcake model for every activity be it design, product or engineering.

And it builds on this thought

)
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade