Why We Communicate With Our Customers Every Day

So, one might ask, why do we do this? Let me share a story from my own experience.

Picture an app owner coming back from a month-long mountain trip, only to realize that the newly introduced app feature appears and functions differently than anticipated. This misstep has already affected the user engagement metrics they monitor within the app. The questions arise: How come? Didn't they clearly outline the intended feature specifics in the task description they provided to the developers? Didn't they appoint a company manager to supervise the development process?

Let's investigate these questions. I'll unfold the story of how my mobile app development team created this very feature. We'll take a closer look at the task given by the app owner and observe where uncertainties originated. Moreover, I'll also discuss our standard practices that help prevent such unwelcome surprises in usual circumstances.

Project Background

Our team has been dedicated to this project for several years. The app we developed is employed by the owner to offer online learning programs. He's been actively involved in uniting app users into a close community and maximizing its growth.

Their initial approach to draw in new users involved distributing promotional codes via social media platforms. We've integrated the corresponding feature into the app. As a result, newly registered users can apply their promo codes and receive a discounted rate for their first service payment.

Moving ahead, the entrepreneur decided to award users with promotional credits when they spread the word about the app to their friends. For instance, users could share promotional messages with their contacts to earn credits, which they could later use to pay for services within the app.

Credits will be assigned by the customer company's managers. As for our part, the customer framed our task as follows:

Enable users to use their credits for paying for services in the app. When a user proceeds with a payment, the system should first check their credit balance and then deduct the amount of their credits from the payment total.

Origins of Uncertainty

Task Addresses Only a Basic Scenario

The core concept of the future app function is clear. However, to ensure its flawless performance without any disruptions, it's important to consider not only the most straightforward scenario but also possible deviations from it. Here's the first detail that raised doubts among the developers: What's the procedure if the amount of the credits goes beyond the service cost? Can a user receive the service entirely for free, using only their credits?

Let's picture this scenario: users purchase photography courses via the app and pay solely with their credits. Could this situation arise? Does the company have a strategy to compensate instructors for potential losses? The developers are not aware of such specifics. When their decisions could carry financial risks, they need clear directions from the customer.

Typically, we would ask the customer for clarifications in our daily report and receive a response the next morning. However, due to the customer's unavailability, we had to redirect this question to the manager designated to guide the development. But the manager was at a loss with this query. They weren't the individual who came up with this feature. The customer's aspirations from it are only understood in general terms.

As a response was absent, our singular choice was to adhere closely to the written instructions provided by the customer. Task description doesn't outline any exceptions, so we have implemented the capability for users to pay for services using credits without any limitations. However, we ensured that the feature is designed to be adaptable for future adjustments if needed. Furthermore, we emphasized this aspect in our daily report, suggesting a double-check for any desired changes.

New Feature Clashes With Existing Functionalities

Another challenge we encountered while implementing the new feature was associated with the specifics of the payment system already present in the app.

The matter is that, in line with the regulations of the customer company, the cost of each particular service is determined within a complex discount structure. Moreover, this pricing isn't generated automatically; it's controlled by the company's managers, who can make adjustments based on the up-to-the-minute market conditions. As a result, the app used to display the user with the payment amount that was communicated by the managers.

But now, the app is in charge of calculating the service price by subtracting the amount of the user's credits. Yet, for this process to occur, the app must have knowledge of the initial service cost, which is absent from its system. Such data was not needed before.

Thus, the newly proposed function doesn't match the pre-existing pricing mechanism. This situation is quite frequent. Throughout the development, we offer the customer thorough explanations and demonstrations of how each newly devised app function operates. However, for the entrepreneur to truly understand all the details and stay informed about the app's internal workings, consistent time and attention are required. If, for some reason, this becomes challenging, the project inevitably suffers. Planning new features without grasping the existing ones is not the most effective approach.

Under usual circumstances, we would collaborate with the customer to address the inconsistency between the credits system and the discount mechanism. One possible solution is to create an app function that can receive data from managers regarding the present service costs. Alternatively, the pricing algorithm employed by managers could incorporate the reduction based on the credits amount, similar to how it handles other discount types.

As the manager couldn't provide a response to this query either, we had to rely on our own judgment. In the end, we implemented an additional data-saving mechanism to capture the service costs communicated by managers during payments. This measure was taken to ensure that we could implement the new function precisely as outlined in the written instructions.

Feature Imperfections Become Evident Over Time

While testing the new feature, an additional problem came to light. The app provides users with the option to make payments using different well-known systems like PayPal, Stripe, and more. Each of these systems has its own minimum payment amount requirement. If the remaining service cost after deducting the credits falls below this specified threshold, the user won't be able to continue with such a payment.

There's a need to fine-tune the new function. This situation is also quite standard. It's extremely unusual for a function to stay the same throughout a project and be realized exactly as the customer imagines. Typically, we constantly refine it as we identify its shortcomings and get a better grasp of user preferences. This meticulous task essentially has no end.

We inquired to the manager about measures to prevent users from facing difficulties due to the minimum payment threshold, but received no response. Since the task didn't mention it, we kept things as they were. So, if users run into this, they have to pay the minimum, which means they'll pay extra.

Task Doesn't Address User Experience

Also, the developers weren't quite sure how to display the fresh payment method in the app's interface. When a user taps on "Pay," they're taken to a page that lists all the available payment choices. Here, users can select from options like "Apply Promo Code," "Pay with Cash," "PayPal," "Stripe," and more.

After integrating the new payment method "Pay with Credits" into the system, an automatically generated button with the same label appeared on the payment page. However, for it to work smoothly, the corresponding code requires refinement and thorough testing. We reached out to the manager, since interface specifics are not mentioned in the written instructions.

We let the manager know the situation and asked for a decision. If the "Pay with Credits" button is needed, the developers will fix any issues and add the time taken to the total. If not, we'll simply take the button off. While awaiting a response, we chose to remove the "Pay with Credits" button from the interface until we receive guidance to add it.

As a result, the option to pay utilizing credits in the app is present exclusively as a hidden capability. When a user executes a payment, the system will automatically provide them with a discount proportional to the amount of their credits. However, the user will only find out about this afterward and solely if they intentionally verify the charged sum on their card and contrast it with the expense of the paid service.

Story Ending

Thus, the entrepreneur conceptualized the credits system as a tool within their marketing strategy. We incorporated the corresponding app functionality following their written instructions. How would one judge the end result? How user-friendly is the new feature? Will it stimulate users' motivation to earn credits? How impactful will it be for app promotion?

In fact, when the entrepreneur came back from vacation, they realized that the promotional campaign didn't achieve the expected rise in new users. It was a logical assumption that the not-so-flawless implementation of the "Payment with Credits" feature might have played a role in this as well. And this assumption proved to be valid, as the metrics started to get better when the app owner recommenced their work on app development and ultimately resolved the uncertainties we faced while they were away.

So, What's the Way for Getting the Right Results?

This story exemplifies the impact of uncertainty in software development tasks. We've seen the sequence of events and their implications, the next question is: What's the way to ensure developers understand tasks and achieve the intended results?

The track record of numerous successful projects in our portfolio suggests that task uncertainty can be minimized. Here are the primary aspects that, in my perspective, should be taken into account.

Initial Written Instructions Constitute Only a Fraction of the Path

Is it all about having a precise and detailed written task description?

It's far from being the only factor. When you contrast the different difficulties developers encounter when trying to grasp their task, I would say that inadequately informative written instructions are the least significant problem. Because this limitation can be overcome if developers can communicate with the customer. In our company, all new tasks are also discussed in specific weekly meetings. This is where we can ask the customer for the missing information that isn't present in the written instructions.

Moreover, irrespective of how detailed the initial instructions might be, they will still prove insufficient because it's not feasible to cover everything. Many vital aspects come to light only over time. Hence, it's of utmost importance for the entrepreneur to be ready for the fact that refining the concept of the new feature will be a recurrent process.

Developers Depend on a Constant Information Supply From the App Owner

In order to make the best choices from the various available options every day, choices that will genuinely benefit the app, developers often require extra information that only the customer can offer. The entrepreneur's and users' preferences, as well as business specifics and the business strategy, can directly influence how certain app elements should be. Yet, developers lack this knowledge.

Furthermore, it often happens that questions arise that don't yet have answers. And to determine what's more advantageous in terms of user preferences or platform profitability, dedicated efforts might be necessary to factor in extra data. This task, apart from the app owner, is unattainable for anyone else as well.

If developers can't find answers to their ongoing questions, that's the biggest factor affecting the results. And this is the very thing that had a catastrophic effect in this story.

For an Intermediary, It's Essential to Be In Sync With an App Owner Regarding Feature Concept

As the project grows, the entrepreneur delegates a portion of their responsibilities to other members of the business team. It can even reach a point where several specialists are responsible for interacting with developers within the team. For instance, the customer might have separate representatives handling the development of Android and iOS versions of the app.

Unfortunately, developers commonly encounter situations where customer representatives give conflicting instructions or remain unresponsive to questions because of an inadequately established process for harmonizing collective decisions within the business team. This leads to delays in application development and it also compromises the outcome.

When customers are consistently hands-on in refining the app's functional details, we deliver a final product that truly serves its intended purpose.

In our company, we maintain continuous communication with the customer through meetings and messaging within the project tracking system. These routines have proven to successfully translate customer intentions into features that align with their business objectives.

Fill out the contact form right here, and we're more than happy to help you reach the best possible results for your project.