fbpx
Share on facebook
Share on twitter
Share on whatsapp
Share on linkedin
Share on email

Amber Labs – A tale of product innovation (Part 1)

Innovation is a trendy word. Everybody is innovating these days. Companies put innovation at the forefront of their objectives and values, while there is an abundance of innovation frameworks and theoretical courses with educational materials describing models of achieving said innovation.


Yet, finding actual examples of product innovation tales, with the mistakes that were made during the concept and development phases and ways to recover from those mistakes, remains a very rare to find information.


Our aim – as a company both stating that innovation is at our core while also actually building innovative products – is to take you through such a journey, in a multipart series, through our path of creating a product that has never been created before (or at least we could not find an example of it until now). We hope that it will be an interesting journey.

 

 

The Idea

The real-estate market is a huge business. More than anywhere else, the real-estate market in the USA is even bigger. There are countless opportunities and millions of active properties on sale in any moment.

Prices fluctuate based on many criteria and the value of two properties can be very different even if only a simple road is dividing the two. Becoming a master of the real-estate market is a challenging task.


This is what drove our partner to think on ways of educating the general population on the true value of the market – based on location, moment in time, property details and many other criteria.


But how does one educate the public on the value of millions of properties available on the market? Is there a market for such a service? Will people remain engaged while educating themselves? How can this be made to be fun? Let us try to find out!

The Concept

A product is made from many small basic building blocks. An innovative product is very rarely created from innovative basic building blocks. Most of the time, innovation is achieved from the way already existing basic building blocks are rearranged in new and interesting patterns to create a new – never seen before – product and address a specific need.


Our partner had in mind the game of trivia as a must have. But there are so many ways to implement such a game. As a basic design building block, the game of trivia has a great track record as an educational tool.


Therefore, our design team started to iterate on ways in which such a concept can be integrated into the real-estate market.


Our market research data was pointing out that the most wide-spread activity in the real-estate business is, unsurprisingly, property browsing. Therefore, we chose to tie the trivia game to the property browsing activity.


Market fit simulations gave us valuable data about the interest such a solution would generate. In fact, one of the market fit simulation campaigns was the most successful campaign our partner has seen up until that moment. We were all thrilled!

The Prototypes and MVP

Doing market research, segmentations, personas, and data gathering is important, but it is still theoretical. Nothing compares to the feel of having an actual product in your hand and having to use it in real life. Thus, the natural next step for our team was to start prototyping.


We chose “agile-scrum” as the methodology we would use during the product development, a decision which was proven later on to be the right one. It gave us the flexibility to easily pivot in different directions while staying lean and saving precious time and partner’s money.


Building a real-estate prototype is more challenging than it appears at first glance. There are many market particularities that need to be considered. For example, the properties listed at any moment on the US market are hosted under hundreds of Multiple Listing Service (MLS) agencies spread across the country. Each of these MLS companies have their data stored in a different format, which makes its aggregation a challenge.


Therefore, we chose to build our own custom backend infrastructure that will host the application data, as well as integrate the heterogenous data from each MLS in order to be able to serve our customers in a fast and reliable manner. The data will need to stay in sync all the time and provide the latest updates in the market to our users.


On the frontend side, our design team was working with many questions to be answered:
    –  Do we build a game or an application?
    –  How do we keep our users engaged?
    –  How do we make it fun?
    –  What features need to be included to support the questions above?
    –  Do we want a social aspect?
    –  Will the potential social aspect be cooperative or competitive? Or both?
    –  What is the art direction?
    –  What user interface fits best? etc.


As we built the first prototype it became clear that the trivia aspect of the game was inherently fun. Thus, we decided to build an extendable trivia system from the beginning, to have the flexibility to easily add more modes later with minimal effort.


There is a tendency in many teams to polish everything from the beginning. A feature is defined, and the team is doing its best to completely implement that feature to cross it off the project plan. We, being “agile”, were guided by the concept that “80% of a feature is built in 20% of the time while the rest of 20% of the feature is built in the remaining 80% of the time”. This gave us the flexibility of iterating fast and coming up with features that were cheap to implement without wasting time and resources polishing them and making them “perfect”. We did not have the pressure of a project plan with items to be finalized in a specific time frame. We were working fast and very efficient from a backlog, time, and cost perspective.


As we were testing the prototypes, market input was telling us that users expect more. Trivia needs to have rewards, so the question was what to do with those rewards. We needed to find a “currency sink” to create a gamified loop of generating currency via trivia rewards and sinking that currency into a different activity.


We came up with the idea that a virtual world would play well in the user’s fantasy of being a “player” in the real-estate market, earning rewards in the real-world trivia game and consuming them in a virtual setting. This is where our biggest mistake was made.


The team was working fast and well. The agile-scrum methodology was working for us. We were feeling great with one another, we had a great relationship with our partner, we were efficient and happy, and the market data was showing us we have a great product in our hand. It was the perfect world. So, when the idea of a new “virtual world” feature was put on the table, all of us – including our partner – were so excited about it and had such a great feeling that it is the right thing to do that we started to work on it immediately without testing the market for it.


We built a beautiful world, with neighborhoods and upgradeable buildings, with forests and cars, and people and landmarks, and engaging mechanics. But of course, when we tested the new prototype, we found out that only a fraction of our target market was really into this feature, as it was way too complex for most of the people and of lesser interest.


We learned the hard way that, even if we start great, with amazing market data and fast iterations, we never have to forget to test often. Nothing new in this learning experience, but we were surprised that it has happened to us. It did make us better as we are now modifying our processes to ensure this will not repeat. Never let a great project experience stay between the team and a market test.


We had a wonderful time building that virtual world. And we took the decision to throw it all away. It was not easy, especially for the artists who crafted gorgeous buildings and landscapes, but it had to be done with no regrets. Again, being “agile”, we did not waste too much time on it and were able to pivot quickly into a new – this time market researched – direction.


We replaced the “virtual world” with a beautiful property fix-and-flip experience. A user would be able to purchase a ruined virtual property and then fix it and sell it for profit. To tie this more into the user fantasy, an advanced events system was introduced into the application. A leaderboard system was also created
to entice users to compete.


We extended the trivia system to more modes – playing on active/sold/pending properties – a task made easy by the early decision to build the core trivia system as easily expandable. This was a crucial decision, since the trivia mode was here to stay, it was well worth it to spend more time in the beginning to create an extendable system instead of spending way more resources later. The new trivia modes simulate well in our market fit research.


Also, being a real-estate application and having all the data at our disposal, we chose to offer the users the possibility of contacting the respective agents in case they are interested to prospect a property. The users can see all the property details available on the market, to browse the pictures and evaluate the amenities.


The product is now a full-fledged real-estate application with features that rival the best-in-class applications, supporting millions of properties in real-time while, at the same time, educating its users. We have social features planned to be included that early data suggests being very desired by the market. We have a lot of features planned and the application is far from being “complete”.


However – applying the earlier lessons – the time now is to test the application with a larger pool of users, even if we do not feel it is “complete”. Hence, the next step is to “soft launch” it. The result of that soft launch gathered data and the decisions which we will make in the future will be part of the second installment of this story.


To be continued!

Related Posts