Why Quality and Velocity both are indispensable to product’s success?

Bhuwan Jain
Feb 20 · 6 min read

When I was in class 6 and my brother was in class 8, every Sunday, my father would sit with us and challenge us for a face-off. One fine Sunday, this was our challenge-

We jumped at the tick of the stopwatch and started scribbling with the utmost determination to win. When the timer stopped, our father took both our notebooks to analyze and declare a winner. While looking at my brother’s handwriting, he squirmed and twitched his eyes, as if trying to adjust light to fill his iris with their correct shapes. While looking at my notebook, he smiled but grew disheartened when he realized I could only list down 12 (not 20!) names.

He rose from his high-back chair, took a deep breath and declared that there is no winner. My brother who had expected to win because he had fulfilled all terms & conditions dropped his jaw.

My father explained his decision-

Decades later, I still remember this story vividly. The lesson which my father taught us about quality and velocity is precious and still stands true.

The reason why I am nostalgic about all this is that recently I was hurled into an age-old debate of in my team. I wanted to tell them this story, but before I could do that, people convinced each other, found a middle ground and safely the topic for the next meeting.

This isn’t new. And our people aren’t the only people who do this. It’s a very common problem and since ages people are struggling to overcome this trade-off.

What troubles me is this- is there really any trade-off? Who would have been the first human to convince the other that it’s okay to delay the ship date or okay to deliver a bad-quality output, and call it ?

While this might be a way too harsh thing to say, especially in the extreme-agile setup these days. We all know that things go wrong, unforeseen circumstances appear, requirements change and as a result, deadlines had to be pushed ahead. But does it have to be a necessary evil even in the most perfect situations?

Certainly not!

What happens when you compromise on the Quality?

When you compromise on the quality, you lose the trust of your clients. No one wants to go to the market with a cranky product. If you think that the product would have been better had there been more time, then you’re at fault for not setting the expectations right with the product owner.

On the contrary, if you had set the right expectations but timelines were hurried from the client’s end, then you should proactively convey the downsides of delivering a low-quality product. While the client would always be in a hurry to launch the product into the market, it’s you who has to make sure that the client understands that ‘re-engineering’ is a costlier option than ‘development’ and it slows you down, even more, when you really need to pace up as more users join your platform.

You need to understand that great products are built when you make quality an integral part of the development process. The product can be scaled in any direction only when you have achieved a desired level of quality. So, even if you are in a hurry, go with things better, rather than doing all things with low-quality!

What happens when you compromise on the velocity?

In an increasingly agile world, founders are struggling to make their idea flourish. Therefore, they go by an aggressive deadline because the is important for them. If they don’t hit the market at a suitable time, one possibility is, they’ll lose their business to some other competitor.

Moreover, investors start getting anxious if they don’t see any ROI. As a result, founders need to get to market i.e. before anyone else hits the market with a similar idea.

So, when you compromise on the velocity, in a way, you hamper their spirits and growth model. You weigh them down with your to deadlines.

So, what’s the solution? Can we have both?

Certainly! I mean, why not?

Start with Agile.

It not only gives you a chance to keep a balance between both the things but also makes things a lot more efficient.

  • Delivering the fully tested features in chunks helps you to keep a fine balance on both Quality and Velocity.
  • You can set the quality benchmark for every release which ensures that you don’t ship a substandard quality.
  • You can also set the release cycle as per the requirement which helps you control the anxiety of going to the market You can choose only a set of features that will go in the first release and keep your focus on quality intact.
  • As you move ahead, you’ll gain a better understanding of how things work, where the team gets stuck the most and time estimation on each story point. So, with experience, you can increase the focus on any area as per the requirement.

Even if nothing works in your favor , I would say that start with quality.

An organization called DevOps Research & Assessment have come up with an interesting theory (based on their research since 2014). The theory says that

That means, once you’ve built your “quality” muscle, it’s easier to train your “velocity” muscle.

A lot of people will say that it’s nearly impossible- that you can’t always root for quality.

There might be some cases when you are not sure what you’re building when you have a vague idea but you want to test it out before going all in. In such cases, quality comes second to speed.

But other than that, there’s no way that you can compromise on either quality or speed. Both of them must go

I really hope this blog gives you a better perspective of how small things make a big impact and help you understand why quality and velocity are too important to be interfered with.

Unboxing Product Management

Your weekly dose of everything related to Product, Process and People.

Thanks to Shruti Sharma.

Bhuwan Jain

Written by

Product Manager @ Quovantis Technologies

Unboxing Product Management

Your weekly dose of everything related to Product, Process and People.