Summary: If you take a look at our website, our price calculating tools, or even the coverage tables, you’ll see the product of our agile development process. Our team of engineers, product designers, and insurance experts use agile development to provide the information people need about insurance.
Delivery Speed
When we think about developing new features and business initiatives, we try to emphasize the speed of delivery rather than ironing out the fine details. Of course, this doesn’t mean we put out half-baked products or features. Instead, we follow a quite rigorous process that includes testing to roll out products and features that can be easily improved over time.
What exactly does this look like? Well, when revamping our dental insurance, we made sure that our most important features worked well and released the landing page. Afterward, we did some A/B testing to see which copy worked the best before finalizing. During that time, many people were still purchasing dental insurance while we got the right wording and design down on the page.
Still, before releasing the page, we spent a lot of time testing to make sure everything worked as intended. After all, we are dealing with people’s livelihoods since many depend on insurance during the most challenging times in their life. That’s why we make sure our products work well and then adjust for the fine details since no amount of in-house thinking can beat a real-life market test.
Lean machine
Whenever we start working on a new feature, we ask ourselves what the minimal viable product (MVP) is that would serve customers’ needs. That way, we can develop new products as quickly as possible while also learning from them. By doing this, we’re using both the lean method and agile development.
The goal of the lean method and agile development is to develop products and features quickly. We start with developing the minimal viable product and then add on features, content, graphic, etc. in increments as we learn more about customers’ needs. Agile development allows us to test hypotheses faster to make better products that fit customers’ needs better.
Although this might seem like standard practice, many other companies follow the mantra of “move fast and break things”. At Feather, we’d rather move fast and gently to allow ourselves the opportunity to take every step consciously, so we can learn as we move.
It’s about the customers
Our approach also goes along with the values we’ve instilled in the product team at Feather. We start the development journey as quickly as possible and treat users with the respect and care they deserve. By doing this, we’ve seen that customers give us the feedback we need to grow and improve.
It’s important to note that when we start the development process, we sometimes only have a vague idea of what the end product will look like. A lot of our early decisions are based on already released products and what customers have formerly told us they need. For example, our price calculators for our insurance products are always well-received, so we add them whenever possible which is why you can see them on the following pages:
- Public health insurance
- Private health insurance
- Life insurance
- Bike insurance
For future products, we plan to add them wherever possible. Still, it sometimes doesn’t make sense for some products like expat insurance where there are two fixed prices depending on the basic or premium plans.
More often than not, we also realize that our original assumptions were wrong about what customers need. And, we’re not ashamed to admit this because agile development allows us to react quickly and move through tight feedback loops to address problems for future customers.
Agility FTW
Even though the Manifesto for Agile Software Development was published 20 years ago, it still forms the revolutionary foundation of software development. Questions like “how do we place individuals and interactions over processes and tools?” or “how can a team respond to change over following a plan?” might seem simple, but are rather complex when organizing a team around the answers.
There are 12 guiding principles that show us how to build complex products or features in a dynamic environment. Each of these principles calls for teams to embrace flexibility rather than following detailed planning and rigid structures. Otherwise, a team risks becoming reactive instead of proactive.
At the same time, humans are naturally ill-equipped to deal with uncertainty. We feel safer with tangible solutions and concrete assurances. At Feather, we try to mitigate this to avoid wrestling with ambiguous results from our decisions by presenting our products early on to customers to gather feedback.
Before including some of our insurance products in German, we opened our German products to a small number of customers to collect feedback and gather information for the next iteration. During this process, we found out that upwards of a third of our daily sign-ups for public health insurance were German speakers. Something we didn’t expect since we’re in the expat market. That’s why nothing is more precious than test results: they show us the direction we need to go while taking off the burden of making a decision from the shoulders of the product team.
Incremental releases
Releasing products and features in small increments saves both the time and effort of all teams when we sometimes find ourselves at a dead end. While most of us enjoy the success stories some start-ups flaunt, we also struggled before finding our success.
When Feather was founded, we had no idea if our products were bringing value to customers since we only had an early (and quite frankly crude) version of our current recommendation tool. The backlinks were broken, and we didn’t sell insurance at the time (plus, no insurance company in Germany took us seriously when we told them we wanted to digitize the application and claims process). It was only through customer feedback that we knew what we were doing was needed. People used the information with our recommendations (even if the backlinks were broken) to search for insurance plans and thanked us afterward.
This is the true essence of Agile at Feather: build, test, learn, adapt, and test again in frequent cycles. Often, we will use external tools to build sign-up flows to learn whether the ideas we developed during the “drawing board” phase translate to actual products our customers use. It’s at this stage that we encourage users to reach out and talk to our customer service team to learn more about what customer needs are not being met and how we can weave them into the customer flow.
Innovation is a shared responsibility
One aspect of agile development that we find incredibly rewarding at Feather is transparency and the close relationships formed within our organization. Because we’re still a relatively small team (but growing pretty quickly), we have the opportunity to freely exchange ideas with one another and get feedback. That way, no one feels like they have to face a problem alone.
Doing that in a remote setting is even harder. Still, we’ve found that by encouraging the team to challenge one another, ask questions, and enable them to test ideas, remote teams can come together and build trust through difficult situations. A good example of this is during Feather hack days when people have one day to explore creative solutions every few weeks.
The true approach to innovation is an agile foundation where people are allowed to step outside the box and know that their ideas will be valued and taken seriously – even if they can’t be implemented. Everyone deserves a chance to see the big picture and think of ways to improve it.
Want to work with us in an agile environment? We’re hiring for a number of positions which can be found on our career page!
Have you heard about Feather’s funding from Transferwise founder Taavet and other insurance investors? We recently raised €3.8M and plan on doing some pretty exciting things in the near future!
Read more
