My name is Viacheslav Mukha, and I'm a Software Engineer at MEV. Today, I'd like to share a case study from our company that illustrates how a product-oriented approach in providing software development services can improve the outcomes and create more value. Not blindly implementing every client request can, paradoxically, make them happier. Let’s explore what to focus on to ultimately solve the business problem.
Once, on the recommendation of a friend (who was our client), the owner of a small logistics company based in the Midwest approached us. This company specializes in freight transport. Over time, the management realized they were missing out on a significant chunk of profit—many trucks were returning empty from their destination when they could have been loaded with additional cargo for the return journey. However, for this to happen, dispatchers needed to promptly locate the appropriate cargo.
Thus, they came up with the idea to develop a platform to:
But, as wise Dave Wascha once said:
“Listen closely to a client when they talk about the problem, but stop listening as soon as they talk about the solution.”
So, instead of hastily kicking off projects, billing clients from day one, and silently building what they request, we took time for a deeper domain analysis and requirement study.
Traditionally, we began with validating the entire project's concept (PoC) and creating a prototype solution. Why is this a fruitful first step when working on a project?
In our case, the prototype was a telegram bot combined with a server that read the GPS data of trucks and received cargo requests. With this bot, we had access to user push notifications, which was more than sufficient to address the business problem. Consequently, the prototype shifted the primary project concept from mobile app development to a much simpler communications tool.
Speed is often a vital metric for business. And it's particularly crucial at the onset of development. By the end of our first working week, we had rolled out our first usable feature, thanks to our immediate focus on core functionality.
For instance, we didn’t even connect a database in the early stages, opting instead for a simple file system. But we employed a library (tingodb) offering a MongoDB-like interface, allowing us a seamless transition to a full-fledged MongoDB when the time came.
This highlights two pivotal points:
What significantly sped up our project work was our practice of having ultra-short releases several times a week. This rapid feedback loop with the client allowed for swift modifications.
But arguably, the most invaluable inputs came from real users. As the system was put into production in just the first week, we received feature requests that nobody had considered during the initial scope agreement. Moreover, much of the functionality previously agreed upon in the SoW turned out to be superfluous.
Naturally, the more feedback you get, the quicker the backlog grows. By the end of the project, 70% of the features had emerged based on this feedback, amounting to an additional 70% to the original work scope.
Given such circumstances, one could take various routes. You could simply develop more features in a set amount of time, sacrificing some level of development quality. Alternatively, you could extend the project duration since these new tasks weren't planned from the get-go but are vital for the client. From a purely service business perspective, at first glance, this might seem like a decent idea since - a longer project equals a more profitable one. However, in the context of product culture, continuous backlog prioritization seems most optimal to bring best value to the client and keep the budget intact.
When we talk about backlog prioritization, we consider two task parameters: their value and size (the time required for implementation). How do these parameters correlate? Simply – they don't. A feature that takes, let's say, a month to develop isn't always more valuable to the user than one crafted in a week. More details on this can be seen [here].
Hence, for accurate backlog prioritization, it's imperative to continuously engage with the client, clarifying what's essential at the moment.
At the article's outset, we discussed that refusing to blindly implement every client request might lead to a happier client. So, did we succeed? I believe the fact that we resolved the client's problem in 2 months and at a fraction of the cost, as opposed to the 5-8 months other companies estimated, serves as the best answer. The primary reason for this success was our decision to change the project's very concept.
For us, this tale didn't merely culminate in another successful case for our portfolio. It also paved the way for a new client, who approached us some time later based on the recommendation of the satisfied owner of the logistics company.
We use cookies to bring best personalized experience for you. Check our Privacy Policy to learn more about how we process your personal data
Accept allPrivacy is important to us, so you have the option of disabling certain types of storage that may not be necessary for the basic functioning of the website. Blocking categories may impact your experience on the website. More information