Shifting from Coding Features to Solving Business Problems

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.

The Players in Our Tale:

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:

• Actively monitor available cargo transport orders.
• Match these orders with the radius of the current truck location (or its intended destination).
• Send push notifications to dispatchers or drivers about relevant orders.
• Given these needs, the first solution that comes to mind is a mobile app. In fact, that's what other companies had proposed to him, quoting a 5-8 month project with a budget exceeding $100,000. The client came to us for an estimate for such an app.

But, as wise Dave Wascha once said:

“Listen to customers… This sounds obvious but it’s surprising how little we actually do listen to our customers. Our job is to maniacally understand your customers’ problems – and you can’t do that without listening to them and understanding them. …but don’t listen to customers. While we should listen to customers about their problems – we shouldn’t listen to them about the solutions. That’s our job.

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.

First Steps – Concept Validation

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?

• You verify if the client's idea is feasible from a technological standpoint.
• Demonstrate to the client that you've understood the business problem and know how to tackle it.
• Identify potential hurdles in the development process well before active work begins.
• Align with the client on the vision of the future product.

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.

Further Implementation - Emphasis on Speed and Feedback

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:

• Remember the KISS principle (Keep It Simple Stupid), especially in the early development stages.
• Maintain the big picture vision, guiding developers to direct architectural decisions in the right direction, ensuring the system is always adaptable to changes.

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.

Last but not least – Attention to the Backlog

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.

Happy End

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.

Conclusions

• Start with Analysis and Designing the Solution Prototype: This ensures that you comprehend the business task and can address the business problem effectively.
  Move Quickly but Maintain a Big Picture Vision: It's not worth investing heaps of time in setting up processes and tools, which, although convenient and accelerating for development, might not be justified in the early stages, especially for smaller projects.
• Strive for Quick Feedback: It's not always possible to fully understand the client immediately, and vice versa. Short project iterations can help avoid these misunderstandings. Ideally, if the project's nature allows, it's beneficial to get real users involved as soon as possible. They will provide the best insights about the product's needs.
• Remember the Principles of Agile: Namely, that individuals and their interactions are more critical than processes and tools, and collaboration with the client is more valuable than contractual obligations.
• Keep a Continuous Focus on Backlog Prioritization: In a fast-paced format with ample feedback, you'll need to refine the prioritization consistently. This involves communicating with the client to determine what needs attention right now and what can wait, considering the value of tasks and the cost of their implementation.