Our approach to product development
We do a lot of things different than “normal” companies, starting with our founders personally handling customer support questions. Our product philosophy is also somehwat unique as we involve our most active users very early on and base a lot of our roadmap on feedback we get from support chats.
“The customer is always right” –
“Build it and they will come”
Which one of these is your product development philosophy?
If you ever started your own company or are in charge of products at a large company, you will agree that developing products is hard. It’s different from other types of work because you cannot see the impact directly. You cannot check whether a new feature is working or not until users start using your product. This makes it difficult to know what needs fixing and how to fix it. ‘Fail fast’ has become the mantra for many organizations that are trying to build software faster, test them with users sooner, and fail fast if something does not work. How do we do that? How do we build the right features? In this post, we will talk about how we develop products at Riddle.
Product Philosophy: There are two distinct camps when it comes to creating products.
You can either religiously listen to your customers needs and build what your customers and prospects tell you they want or you can create what you believe to be the best product and hope that the market will love it.
Henry Ford famously said: “if I would have asked them what they want, they would have said ‘a faster horse’”
As usual in life, there is also a middle ground when it comes to product philosophy, which is how we like to create products and features at Riddle.
Take our new branching logic feature for example. My co-founder Mike explains this feature in great detail in this post on our quiz maker documentation.
We have made quiz making tools since 2014 and engage with our customers daily through our support chat and email. Our founder-led support allows us to capture our customers thoughts, ideas and suggestions immediately, without any filters that an external customer support team would add.
As the quiz creation market has evolved throughout the years, quiz creators are becoming more ambitious and how they want to create quizzes. To get the best out of a quiz, it has to be engaging and provide real value to the quiz taker. If you manage to provide that, you will benefit from:
- A better SEO rank as your time on site will massively increase when people spend 3 to 7 minutes completing a quiz
- Free traffic from social shares as quizzes are still the most shared content on social media
- Highly qualified and segmented leads if you add a lead form (or multiple lead collection fields) to a quiz. A quiz based lead generation process can get you a 35% sign-up rate vs. 0.5 to 1% sign-up rates from pop-up forms.
To make a quiz more relevant to the quiz taker, you often need to tailor subsequent questions to how previous questions where answered.
For example, if you create a quiz “How well do you know London?”, you might have a different set of questions for people who answer “yes” to the first question: “have you ever lived or do you live in London right now?”.
When talking to our customers it became clear that logic jumps and branching logic is one of the key features they want to see in a quiz maker like Riddle.
However, almost everyone we talked to had a different idea of how this could work. You could either send people to a different branch based on which answer option they picked, or how many points they scored in a question or how many points they accumulated in the quiz so far.
The challenge for our product team was to come up with a way to build the most flexible logic builder imaginable without making it so cluttered and complicated that no one would ever use it.
Our product team has done a great job creating a super flexible logic builder that covers every use case our customers and we ourselves could possibly come up with. They managed to put all that into an easy to use interface, which needs minimal explanation and is very intuitive to use.
Of course, we may be completely wrong in our assumption about the ease of use of Riddle 2.0, which has flexibility when creating at its core.
In our approach to development, we also love the “fail fast” route.
This product philosophy mandates that we are getting real users to try out products even if they are not fully ready, helps validate a product concept early in our product development process. It is also based on our founders and engineers leads handling customer support most of the time. This way, suggestions for improvements and bug reports are not filed away and forgotten.
Even before we have written a single line of code on in our development process we start sharing product outlines, screen designs and feature lists with some key customers. Most of our product designs start with our product managers creating a Miro board with a rough product outline before our UX team moves on to create clickable prototypes in InVision. Once we have something that actually works, we immediately open it up for testing to a small list of users before creating a public beta version for everyone to play with. The Riddle 2.0 beta is a good example. While we urge our users to keep on using the current quiz maker for any live projects, we give public access to our next generation quiz maker, even though we know it is not fully ready for production use. Within the first minutes of its availability, we already collected over 23 user comments and suggestions on how to improve our product. With subsequent bi-weekly releases, beta testers can watch how the product evolves and how their feedback is making its way into our quiz maker.
Let us know in the comments or through our support chat on riddle.com where we failed or did well. You will have the Riddle founders answering your questions and suggestions personally.