My Flubit Journey Part II
After a year, we are on the verge of launching the new flubit 3.0.
Last August the situation was very different. We’ve changed and scaled every bit from every corner of the flubit platform.
We have a different concept, business model, development approach, interface design, and style. We’re using new frameworks, APIs, systems, servers, database technologies, sub-versioning systems and much more.
The image below suggests how much we’ve changed
As we discovered, we needed to be more agile in building the new app. The whole development process now tends now to be a test-driven development and a continuous integration process.
We have a brand new, original interface.
As you will be able to see for yourself shortly, the most important rule for our new website (usability-wise) is to keep it simple. All the links speak for themselves, the structure is now predictable, we provide clear and visible feedback, informing our users and making it hard for them to make any serious mistakes.
We have a series of innovations.
We needed to innovate in a time of rapid change in the e-commerce market. We needed to have enough evidence to confidently answer all the questions faced when inventing a new product:
– Will people want to use this kind of service?
– Will people buy with it?
– What should it look like?
– What features should it have?
And so on…
We had to validate our ideas.
Because we had to have confidence in our answers to those questions, we measured progress by what we learned through experiments. The goal is always to act on learning, finding product success through repeated cycles of ‘build-measure-learn’.
We first proved that customers wanted our new concept, and would be willing to purchase items on flubit. We experimented, and sold to a small number of customers (we called it Project Fireworks). Only then did we make the move of growing the company and started work on what we call flubit 3.0.
For the flubit 3.0 journey, we’ve done it all – from pair programming to code refactoring – trying to follow these lovely principles:
– people across functional areas (programmers, testers, writers, marketing, product managers…) all work together as one team rather than different groups working in ‘stages’
– iterative development (working in short development cycles with focused objectives)
– incremental development: keep making our testers happy, and have frequent releases
– focus on human communication (so no APIs between them please)
– continuous feedback from all involved
Work is now organised into the smallest possible batch size, and launched quickly. The idea is to learn as quickly as possible from product decisions that are effective, reducing risk and wasted time and effort.
The interface is now a sexier, one-page website using parallax scrolling. The database is now larger and it’s using NoSQL as a novelty. We have a subversion system to allow and facilitate faster development from our larger programming team (we’ve grown from 2 to 9!), and all of that is built around a great extended PHP Framework.
All this means flubit is now powered by systems that have a better understanding of our users’ demands, matches products and builds effective deals; understands the configuration of the user needs, tracks visitors and our marketing campaigns; and communicates with external systems using brand new APIs.
Not to forget, we also made a huge and (we hope) funny video campaign. Just go to www.flubit.com and see it for yourself.
We have more lessons to learn, more learnings to apply, more improvements to our application so the Kaizen (A Japanese term for continuous improvement of processes) will be our state of mind. Also expect to hear, see, feel and (maybe not) smell us and from us more and more in the future.
The marketing department will start the noise!