What defines a mature product?

Apr 30, 2024

The devil’s in the details. After weeks of programming, the phase of refinement begins. The speed of development is extremely high, but in the meantime running projects continue. The bar is set high for the usability and speed of Rulecube Forms. In our design phase, we emphasized the value the user is going to experience from Rulecube Forms. From our own standards, however, we set strict requirements for how that value should be created. Wherever we can, we always enable intuitive features such as drag-and-drop and Wysiwyg: What you see is what you get – a way of configuring/building that uses a visual interface, where you can see the end result of your work as you work. The big question soon becomes:


Just how good is good enough for an MVP?

So the discussion is: which quality criteria are immutable and which are icing on the cake that may also come in a subsequent release. In the end, we fall back on our core values and the promise we already make to our customers with our platform. Automatic documentation, security, transparency and thus the ability to audit, version control and backwards compatibility, all those features we promise for the Rulecube platform, should also apply to Rulecube Forms. The speed that is part of our core values is also non-negotiable.

We are deferring a spectacular visual builder and a few other features that mainly benefit usability to a second version. Since we work short-cycle, that second version won’t take very long anyway. The most important question remains:

Are we providing the value we promise?


Because of our reverse designing development approach, we started talking to – potential – customers at a much earlier stage than usual. Now that our process of building is at an advanced stage, we are showcasing our product. That generates a second round of feedback. Those conversations reveal new needs and even new drivers to consider Rulecube Forms. Only when there is sufficient confidence that you can help solve their problems do people fully open up. On the one hand, this is a great signal that we are on the right track; on the other hand, it also reveals product requirements that were not yet in scope for the MVP.

This is where we experience the biggest difference from traditional development. Previously, we only collected this second round of feedback with a launched MVP. Until then, we built inside-out, relaxed from our own intrinsic motivation and conviction. At any point, there was still the freedom to change direction. At the launch of the MVP, you closed the first stage with a party. Now we established the end state at an early stage, also towards the intended customers. We’re giving commitment for the value we’re going to provide. The feedback comes earlier and obviously we have a professional drive to incorporate that feedback into our first MVP. That makes the development process considerably less casual and relaxed. And some on the team are feeling a little affected by that.

The short feedback loops are great in how they prevent you from wasting development time on the wrong things. But it requires more in terms of managing customer expectations and safeguarding job enjoyment.

With a sharply defined scope, we plan the date by which we want to have functionality completed. To estimate the final go-live, we add time for stabilization and testing. It will be hard work until then, but the go-live is approaching. And our pride in the final product is growing more and more.

Long before the MVP comes the prototype. Want to know how we can help with ideating and prototyping? Check our innovation lab. 

Read more