Software quality has no alternative

A digital project always lives in the tension between money/time-number of features-software quality. Software quality must never be sacrificed.

The whole video on YouTube

A digital project always lives in the tension between money/time-number of features-software quality. Our core message is never to sacrifice software quality in favour of one of the other attributes. All right, there is one exception, and that is throwaway experiments. But otherwise, there is no alternative to software quality.

What are the dangers of cutting corners on software quality?

On the one hand, you often don't notice it at all. You build features and build and build and only at the end do you realise: all the features are perhaps quite nice for the marketing of the product. But in practice? Not usable. Too many bugs and no good user experience. The quality is simply not right.

Only exception

I want to learn and perhaps build several small prototypes. I want to test these with users and gain insights into which variant is best received. In this case, it is absolutely fine to say: this is a disposable product. The quality doesn't matter. The focus is on learning and generating knowledge.

Now, if you are a start-up, you might find yourself in the tempting situation of continuing with an actual disposable product and developing on it. You build up more and more technical departments if you decide to do so. It's best to start from the very beginning, from the point where you are really building a product for the market: focus on quality!

What is a meaningful MVP?

The key is to choose an MVP that has a high benefit even with just a few features. The goal here should be to iterate the features and make them so good that users have a benefit.

In our view, this is the best prerequisite for displacing other competitors in the market: doing one thing, but doing it very well. This also fits in with the agile approach. Don't iteratively string together more and more half-finished features, but iterate on the few features and make them better.

A great example that immediately comes to mind is our project with the Startup Erium. At the beginning, there were a lot of great ideas about where the product could go. In a great product development process, we took a focused direction and limited ourselves to a few core features. We fully developed these, iterated and did user tests. We didn't try to squeeze as many features as possible into the given budget.

What else awaits you in the current episode...

We explain why one should concentrate on the few features that have a high benefit. We look at how to find a focus, because this must exist even under time pressure. A UX process helps to set this focus. And the best practice is definitely to set up a project as a "fixed budget with variable features". Just like Scrum sprints.

Written by: