Das ganze Video bei YouTube
A digital project always lives in the tension between money/time-number of features-software quality. Our core message is, never sacrifice software quality in favor of one of the other attributes. All right, there is one exception, and that is throwaway experiments. But otherwise, software quality is without alternative.
What are the dangers of saving on software quality?
For one thing, you often don't even notice it. You build features and build and build, and only at the end do you realize that all the features may be nice for marketing the product. But in practice? Not usable. Too many bugs and no good user experience. The quality is simply not right.
The only exception
I want to learn and maybe build several small prototypes. I want to test them with users and find out which variant is the best. In this case it's fine to say: this is a throwaway product. The quality doesn't matter. The focus is on learning and generating knowledge. Now, if you are a startup, 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 Dept if you decide to do so. Best from the beginning from the point you are really building a product for the market: put the focus on quality!
What is a useful MVP?
The key thing is to choose an MVP that has a high value even with just a few features. Iterating the features and making them so good that users have a benefit should be the goal here. From our point of view, this is the best prerequisite for displacing other competitors in the market: doing one thing, but doing it very well. Fits also to agile approach. Not iteratively stringing together more and more half-finished features, but iterating on the few features and making them better. A great example that 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 testing. We didn't try to squeeze as many features as possible into the given budget.
What else you can expect in the current episode...
We explain why you should focus on the few features that have a high benefit. We also go into how to find a focus, because this focus has to 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.