Building a functional MVP in 3 weeks

by Abhishek Bagalkot | Nov 18, 2020 | case-study

Table of Contents

The problem

The customer is Gartner award winning SAAS company. As their clientele grew, they felt the need to focus on account management and streamlining customer contract renewals. Most CRMs focus on new customer acquisition but account management as a practice has little software support. In this MVP we developed

1. a new concept for streamlining account management

2. software for visualising account health

3. software for account management teams to collaborate

Here we elaborate how we learned a new tech stack, managed and prioritised dynamic requirements while running discovery and implementation in parallel. We released a functional MVP in 3 weeks time; 150 hours of team effort.

The approach

*Innovation projects are inherently risky. They make several ‘leaps of faith’ like customers ‘will change set behaviours’, ‘engineers will solve technical problems’ etc. But risk is not uniformly distributed across a project. Most innovative part of a project (‘the untested hypothesis’) is the riskiest.*

Efficiency is doing things right; effectiveness is doing the right things.

Peter Drucker

Fortunately for us, the riskiest parts are significantly smaller than the whole project.

When we first learned about the problem we figured that at the core of the problem was to build an intuitive and intractive visualisation of account progress where managers and executives could collaborate and make decisions. To encourage adoption, we wanted this visualisation to not just be ‘accpetable’ but also to create a buzz and generate excitement. For creating a beautiful, interactive, browser based visualisation we realised that we needed a very versatile browser visualization platform. [D3](https://d3js.org/) was a clear choice for this.

At that time no one on the team knew D3. Given we had to finish the project in a very short time of 3 weeks, this was a challenge. So we decided not to wait for requirement freeze before building the D3 component. Instead we conducted requirement discovery and implementation of D3 in parallel.

An advantage of this, engineers were able to give ideas on the implementation even while learning D3. They gave feature alternatives and designed tech stack in parallel. This brought more technical clarity to the project.

In about 3-4 days the engineers were comfortable with the framework (aren’t full stack devs awesome!), and we had a pretty clear picture of what was feasible and how to build it.

At this time the exact features of the release were not finalised yet. Traditionally this would be another sign for the developers to take “time out” and wait for clear and stable requirements.

But! We were running a tight ship and did not want to pause work. So we decided to proceed with some assumptions. At Akrity, we are confident that well written codebases with well thought requirement assumptions can be easily extended when final requirements emerge. Even better, working software with imperfect features accelerates decision making and rapidly brings clarity in software requirements.

The team took a judgement call on the most essential requirements and the engineering team developed an extensible DB schema for these requirements. An extensible client server communication pattern was envisioned: query the server through an API, server responds with a JSON, client consumes this JSON and draws itself. First we built a static page that would draw the visualization from a static “hardcoded” JSON (which in the final version would be queried from the server). This “semi-dynamic” D3 feature also implemented some rudimentary user interactions (changing values and redrawing with user input etc). Once we shared this semi-developed feature with the customer, the customer spontaneously responded with clarity on what they wanted in final version. This was unlike when we were communicating through static mocks when it was challenging to agree on “imagined functionality”. Next, while the product manager and the product owner were finalising the visualisation feature, engineering was implementing other parts of the app. Once the DB schema and the API calls were clear, we were able to say for sure what elements would be drawn on screen and where. At last, we started fetching the actual data from the API server and let go of our hardcoded JSON.

The results

When the developed MVP was shown to the management, the team approved the MVP at once. This was a major milestone as organisation wide innovation projects typically require long decision making phases for top management. To their credit, the customer had already laid the groundwork on how they wanted to streamline account management process. The MVP fit in their processes perfectly. The MVP was presented to all employees at the annual meet as the new way of account management in the organisation. A new set of requirements that would “operationalize” the MVP were quickly finalised. Budget was approved for further development and release. Within 150 hours of teamwork and 3 weeks from start date, the Akrity team were able to develop a MVP that started a new account management process in the organisation.

The future

The customer is considering exposing part of the platform to their clients so the clients could eventually self-serve themselves and become a partner in ensuring their own serviceability and renewals. Given ensuring renewals is a common SAAS problem, it is also a possibility to spin this off as a new product line.