Case Study: The journey towards an MVP

The journey towards an MVP

The world is filled with products that no one has ever heard of. Everyday talented teams of engineers and designers come together around an exciting opportunity and employ the latest principles around delivery. All these things provide value, but here at FinLeap, we know that it is not just about building any product. It is about building the right product with the right market-fit. As simple as it sounds, this is the main challenge which keeps pushing our product team every day. In this post, I will briefly introduce some core product development techniques suitable for a fast-paced startup environment, plus how we turned theory into practice.

One concept which has gained traction in the industry during the last years is the Minimum Viable Product, commonly known as a MVP. In the early phases of product development uncertainty is high and the  assumptions are many. The MVP embraces this by aiming to deliver the “maximum amount of validated learnings with the least amount of effort” or, in other words, a product consisting of a limited feature set which is sufficient to demonstrate why early adopters should care. Great. Makes sense. Now where do we start?

It’s all about the assumptions

 At first your idea or opportunity will be based on a large number of assumptions. Assumptions are natural early on, but it is important to deliberately move forward knowing which are worth validating, and which can be accepted. Too many assumptions and you risk your success being attributed to luck rather than skill. Too few assumptions likely indicates you’re playing it safe, and you run the risk of being overtaken by one of your competitors. To validate and remove some assumptions, it is helpful to perform market research, talk to industry experts and do user interviews. How to collect unbiased information from these and not “what you would like to hear” is a topic for another article.

With a solid set of starting criteria and a high-level business case built around “what problem are you trying to solve and for whom”, it’s finally time to talk about building things and deciding how to scope your MVP.

Should I build a MVP?

As a company builder, it’s essential to identify potential for market disruption early in the process. This could be triggered by the emergence of a new technology, a new player or regulation, leveraging data in an innovative way or a change of customer behaviour. We believe that Customer Service is one of these opportunities.

After identifying our market opportunity, it became time for our venture builders to get to work. A new idea brings excitement, but to avoid false-starts, it is important to ground enthusiasm with reality.

• Is the problem we have identified a real problem for the industry? Or an artificial one?
• Is the market ready for a solution? What role do regulations and preconceived notions play? Is educating the industry a precondition for adoption?
• With the pinpointed problem-solution fit, is it possible to build a business around it?

Clear answers are rare this early on, but it is important to drill down and identify the best starting point. The earlier this is done, the earlier the product team can shape the roadmap around the build-measure-learn cycle that will help you make the right decisions along the way.

Scoping our MVP

In our project, we started with a deep dive into market research. We spoke to traditional call centers. We scheduled interviews with customer service professionals, both agents interacting with the end customer and team leads responsible for the performance and quality of their team. In addition to this, we invited representatives from the FinTech startup community to share their challenges around customer growth. In parallel, we started looking at cutting-edge technologies like machine learning, chatbots and others suitable for automation around a text based media. Thanks to the FinLeap universe and our industry network, we were able to go from idea to problem and initial business case in just a few weeks.

When we felt confident with our assumptions, it was time to feed them into the product development. Being a B2B2C product, our learnings needed to be shaped around the value we could deliver to our business partner, while still having the needs of the end customer in mind. Also, when stepping into a field with existing solutions on the market, utility features needs to be discussed. For example, user management might not win pitches, but ignoring the basic needs of your customer could stop you from getting in the position you need to be to generate value in the first place. After going through the problem solution fit, we decided to scope our MVP around the following pillars.

• Value: Simple structures in conversational data have the highest automation potential
• Value: Companies would use modern chat channels, like Facebook, Whatsapp, if it was easy
• Value: CS agents need a simple tool that just works, not a feature jungle
• Utility: CS supervisors and admins need a set of basic functionality to do their job
• Tech: Machine learning would allow us to do things simple rule-based engines just can’t

 Our aim was to deliver a workable solution, including two user interfaces and a data training solution, within 3-4 months. To reduce the need for time consuming alignment and decision processes, our CTO put together a small development team containing the necessary skillset to be self-sufficient. More developers can work more hours, but do not underestimate the price you pay for communication overhead. A few product artefacts, especially requirements, were prepared while the team explored different technologies, but most of the artefacts were created in parallel with the development cycle. Every week we sat down together and discussed what the team felt they could deliver, while also looking back on last week’s deliverables. By working in one week iterations, we could get into a good pace and clarify misunderstandings or update the MVP scope early on.

Next steps?

During MVP development, through continuously delivering working code, our early adopters were able to trial live demos within 8 weeks of getting started. This enabled collection of early feedback, and I am convinced it was also valuable for filling our sales pipeline. After three months of intense work, we have delivered our MVP and are about to ‘officially’ roll out to our early adopters for use within their daily operations and processes.

While we collect live data, now it is a good time to return to our assumptions and validate if we are on the right track. With an existing product being used everyday by a growing range of customers, we are ready to enter the next phase of product development. Using techniques like continuous delivery, we are well-positioned to deliver and learn every week. What an exciting place to be a product person!