In this guest post, Tom Layfield, Product Manager at Simply Business, discusses lean product development in a traditional industry.
There are some industries that just aren’t sexy. Think manufacturing, finance or telecoms. They’re often resistant to change, slow-moving, and laden with bureaucracy. The flip side of this is that they’re also often ripe for transformation—look at Mint for personal finance, Wonga for short term loans or Grasshopper for phone systems. In this article, I’ll be documenting my experience working for a company that’s adding a modern twist to a traditional industry, insurance.
Forget what you heard
By definition, traditional industries have a lot of history. With this history, certain assumptions are formed about what is and isn’t necessary and often go years without them being challenged. In these situations it’s good to step back and take a fresh look at a problem; it might surprise you that there’s often a seemingly unorthodox solution that works a lot better.
Case Study #1:
We were designing the user flows for our MVP and stripping out everything we didn’t absolutely need when we got to a crossroads. To understand this story, you have to understand our position in the market – we’re an insurance broker, meaning that we sell products on behalf of other insurers and offer a comparison to our users. This is a big selling point for us, with a lot of our highest converting ad copy along the lines of “Get a quote from 7 insurers!” Anyway, our initial flow was as follows:
- Get vital business details for a quote
- Select cover options
- View quote comparison
- View T&Cs
- Buy policy
That was until one of our team suggested that we completely remove the quote comparison element and simply provide a quote from one provider. I thought it was a strange idea, but after some resistance decided to go with it all in the name of lean – i.e. not building what we don’t 100% need.
The results were astonishing: to this day we’ve not had one customer asking where the quote comparison is. That’s not to say that a comparison wouldn’t benefit us in the future – past research has shown that each time we’ve added a new insurer to the comparison panel in our main product, the conversion rate has increased. The benefit of the approach we took, however, is that we could release our MVP faster.
Don’t be afraid of a bit of manual labour
Simply Business has been around since 2005, and as a result, there’s a lot of infrastructure in place. We process payments online, send out documents to our customers, process renewals automatically, upkeep a call centre that deals with sales, customer support and claims, and an abundance of other elements that allow us to run smoothly on a day-to-day basis. As you can probably imagine, developing a product to incorporate all of this from the word ‘go’ would be incredibly challenging. So, the solution was simple. We didn’t.
Case Study #2:
We ran our first couple of iterations focused solely on the first interaction with our customers, our quote form. Things were going swimmingly – we were gathering lots of qualitative feedback from our users and our page to page conversion rates looked good. Still, there was something looming in the background – the masses of back office processes that would need to be catered for to actually start selling policies. We’d typed up a detailed roadmap, and mocked up flow diagrams for both the current system and the desired system, but this only reaffirmed the fact that there was a huge amount of work to do – most likely over 12 months’ worth if we were going to do it all at once.
Luckily, most of our team were either reading or had read The Lean Startup at the time. Inspired by some of the great case studies documented in the book, we set out to create an MVP of our own. We swapped out our CRM for a number of spreadsheets, took payments manually over the phone rather than online (which gave us a great opportunity to get yet more feedback), sent out policy documents manually via email after payment was taken, followed up leads directly from a dump of our database, and so on.
This not only allowed us to start selling (and learning) quicker, but gave us a granular view of what needed to be done in the coming months. From then on, we’ve treated the back office like any other project – defined metrics focused on efficiency (time taken to process policies and customer calls) and quality (churn and number of complaints), and prioritised tasks based on what improves the metrics the most.
Sacrifice short term pain for long term gain
One of the core goals for our company is to improve the reputation of the insurance industry. We aim to do this by selling them transparent, quality products whilst giving them access to great customer service. Now, this doesn’t really fit with lean, a methodology that would require us to initially iterate from swiftly-made but ultimately lower quality product to get to where we wanted to be more efficiently. But…
Case Study #3:
Our first release was prompt. Even more prompt than we’d initially expected, in fact. We’d mocked up some wireframes and our development team had used them as a framework to get the front end up and running. All we were waiting for was some design resource, something which was at this particular time hard to come by as our in-house team was tied up with another project. The decision was made to release the lo-fi prototypes on their own—this essentially means we would be redirecting PPC traffic from a branded landing page to our black & white prototype.
My assumption was that the bounce rate would be sky high; that users would be wondering what the hell was going on. But to my amazement, it was fine – around 5% lower than our projection for the designed page. This also gave us an opportunity to split test different UI elements for our users to select their shop types, before we wasted time implementing them into a hi-fi design.
We concluded the test after a few days, and came out with a lot more than we thought we would. We had convincing feedback from our users about which shop selector was best and we learned that design was unlikely to have as big of an effect on conversion rate than we thought it would, and we did all of this by simply lowering our standards of what we would release.
Note: When we did implement a vanilla hi-fi design the continuation rate was upped by 4%, a percentage point smaller than our projection.
Set yourself up for failure
For traditional organisations resistant to change, failure is likely to have much more of a perceived impact. People are looking for any opportunity to shun a new approach to what they’re comfortable with, so it’s important to note that it’s likely to be part of the transition to a modern development process. Fail fast and make sure you learn from it.
Thanks for reading. If you’re working in a ‘boring’ industry at the moment, hopefully this will show that modern product development isn’t just for tech, and if you’re not, well maybe this will encourage you to go and ‘disrupt’ one of these industries yourself.
Discover more content on Lean Product Management.
Comments 2