In my previous two posts, I described the Simplicity / Functionality diagram and explained what the pitfalls of certain strategies are. In this third and final post of this short series, I will explain our vision on getting to Quadrant 4.
For Triggre this means that it is usable by business users, who have no technical knowledge, and think in terms of business processes and applications that support those processes. This usability must be combined with our aim to become 1000 times faster than traditional programming. Or in other words, 3 orders of magnitude faster.
The first step
We first started with the idea that ultimately led to Triggre in 2009. What we envisioned was a software platform that was so easy to use, and so fast, that you could pick up your smartphone and make a change while doing your daily commute with public transportation. Going from a vision to a product, especially as technically challenging as Triggre, is a big step. That’s why we decided that it would be best if we first introduced a Minimum Viable Product (MVP).
That product was designed, developed and tested between 2010 and 2013. By then, it still very far from our goal. It was fairly easy to use, but required a low level of technical knowledge to really get the most out of it. In the hands of experienced users it was fast though.
When creating the Triggre Benchmark, the record was set at 140 times faster than programming. That meant we were well over 2 orders of magnitude faster than programming. It was a big win for us though, since we had proved that the technology could work.
With our MVP we had immediately entered Quadrant 2, though we were far to the left and not that high up.
Steps toward the Holy Grail
By now you understand that in order for us to ever reach Quadrant 4, we would have to do something drastically different at that point. Becoming easier to use while offering more functionality is hard as it is, but our challenge is to combine this with a third order of magnitude in speed as well.
So our first move would be up, and then right, which requires a completely new concept. Preferably one that is prepared to subsequently move right in the diagram (at least a little bit) too and allows us to increase the speed as well.
Where the first point in the diagram is our first release, point 2 in the diagram is our recent release, code name Gulliver (September 1st, 2017). We gave it a code name because internally simply referring to Triggre wouldn’t work, since building this new version would take a long time.
For Gulliver, we went back to the drawing board. We decided that we should forget the Triggre Designer as it was then completely. We would throw everything away, and design a completely new concept.
Because with the knowledge we had acquired during the development of our MVP we could now design a new work flow that would solve those things that our customers still found hard to do in our first version. Instead of putting a band-aid on those things, we redesigned Triggre completely, aiming to achieve all of the big, hairy, audacious goals we had set.
Another order of magnitude
With a completely new concept, we already knew we were going to be able to develop applications much faster than before. Currently we are making a new version of our benchmark, to reflect this increase in speed, and we have a new record. Triggre is now 337 faster than programming at the maximum end of the spectrum. Not quite 1000 times, but not bad either.
While we were designing our new concept, we anticipated many more improvements. But to make sure we wouldn’t be developing forever, we scaled down our development as much as possible to get the absolute minimum of functionality that would work. That means that we still have many options to improve speed and ease-of-use, allowing us to move right and slightly up even, in the diagram!
More to come. And more. And more.
Triggre as it is now, is already a product we are very proud of. And the good news is that it will only get better. Our new concept allows for many more improvements that we will be making in the coming years, with each release either increasing functionality, improving ease-of-use, or increasing speed. The last two releases are already testament to this continuous improvement strategy.
Only 2 weeks after our big release on September 1st, we released our first improvement to increase functionality. We added new functions to our very easy-to-use rule editor, making it possible to create even more powerful business rules in an even simpler way.
Another 2 weeks later, on September 28th, we released a change to our data model that allows you to manage small lists in the designer. This means you will need less data items to achieve the same thing, while being easier to use. In other words, this release moved us up and right in the diagram at the same time!
Most recently (at the time of writing), we released a huge improvement. When you create a data item, you almost always want to be able to add, edit and remove those items using flow parts. That’s why we now generated those flow parts automatically, and keep them up to date as you change your data model. This increases development speed immensely.
We never give away what we have planned on our roadmap, but rest assured we will keep the improvements in speed, functionality and ease-of-use coming your way for a very long time!