Source: DOU.ua

Why should developers care about business value?

Hi! I'm Oleksandr Korop, Senior Software Engineer at AMC Bridge. I've been working in IT for 8 years, specializing in developing 3D graphics for the web with JavaScript. I've witnessed many examples of successful and failed projects in my career, and today I'd like to share my thoughts on how a programmer can contribute to project success. Instead of focusing on the importance of technical knowledge, I'll tell why developers should understand client's business goals.

You may wonder why you should even care about business value and what it has to do with your job. The answer is simple: the understanding of business value is the tool that helps to see the technical task at a new angle and get a clearer picture of what needs to be done. Some developers consider this approach excessive, but under certain circumstances, it becomes crucial and affects your success.

Let's be clear from the start: this article is not about the soft vs. hard skill debate. It is also pretty subjective. I based it on my experience of successful and unsuccessful projects, holding and undergoing interviews, and information sources that formed my opinion.

In this article, you'll learn what business value is, how to see and test it, and whether your job is really done once you fulfill the formal requirements. If you want to get a better picture of the product you are working on, you'll find plenty of interesting stuff here.

Bitter mistakes

I'd like to start with the most motivating bit: what happens when developers limit their job to the technical part. I won't hide the details of bitter mistakes I made myself or saw others make and share examples of business goals not being reached or delivered to end users.

Case one. In the first project I'll share, the client controlled the development process and acted as both the product owner and a part-time product manager. He participated in our daily stand-ups, ticket creation, planning, retro meetings and kept his finger on the pulse in any other way. Despite that, we could complete the tasks set by him to the letter, and he would still be disappointed. "I expected that feature to let users do this and that, and that didn't happen,"—he would say. Imagine our astonishment at his disappointment despite us following his exact requirements. We found ourselves in a situation when the result didn't meet the client's expectations. This case isn't unique; I saw that happening many times, particularly in the freelance world.

Case two. There were also less trivial cases. Once, we worked on moving a desktop app to the cloud. One of its key components—a very cool feature—was extremely hard to develop, and the client's team was particularly proud of it. We had to figure out how it worked, so we had many meetings with the client's team to learn how they realized it. It was only when the product manager joined the process at some stage of the development that we learned that that core feature wouldn't be there in the cloud version. "Our end users don't use it in the desktop version,"—he said. The case was twice as bad: firstly, an excellent job turned out to be useless; secondly, the developers learned about it only half a year later. I won't exaggerate if I describe that meeting as dominated by very strong emotions.

Case three: the last drop. Imagine a team working on new functionality. Everything goes up to the plan: the development follows the documentation, the requirements are crystal-clear. Then it becomes obvious that a few extra work packages or the client's feedback is required to finish the project. The client thinks that your new suggestion exceeds the planned scope and doesn't give the green light, and so the final touch is put aside for some indefinite time. What happens there? The whole feature goes out of the window because it hasn't been initially planned, and a small amount of effort has been denied. In the end, the user doesn't get a possibility to do something new or do it faster, and the client doesn't get the value that could have been monetized.

That's not our fault!

The cases above spring from different sources: poorly formulated requirements or their poor execution; lack of time or expertise; the crutch that doesn't do its job, and so on. The result is always the same: the business doesn't get value from the app, the user doesn't get the new or improved functionality or better user experience.

"That's not our fault! Why should we bother? We are engineers,"—some of you may say. However, in my view, developers directly influence the product and business. It might be difficult to see working on a large enterprise project, but it becomes very clear on a small start-up project. I'm currently working on a small project at AMC Bridge, and below I'll share my insights.

An example of successfully added business value

The project in question is an orthodontics health care product for individual dental prosthetics. The use case is as follows: the clinic makes a 3D scan of the patient's jaw, the technicians process the scan, the doctors approve the result, and the hardware team generates the model of the prosthesis and prints it. The patient gets the prosthesis done by the same company with minimal effort, and it fits perfectly. As you see, the company runs a full life cycle, from scanning to manufacturing. In that case, it's easy to track how the decisions of specific developers influence the result.

What were the business goals?

The business wanted to eliminate or at the very least minimize the problems that occurred when technicians worked with files. For example, they used to download the scans to desktop, process them in several different programs, and then manually upload up to 20 files to the cloud. The process was error-prone and very time-consuming. Therefore, we set the business goals as to:

• Move the process to the cloud.
• Reduce the time for scan processing and concurrent errors.
• Send the results to the doctors as soon as they are ready, not at a fixed time once a day.
• Make the interface more intuitive while preserving its functionality.
• Merge several apps into one to minimize downtimes and speed up performance.

The goals the client set for the team

• Move from desktop CAD apps to cloud ones.
• Integrate 3D scanning equipment into one system through the IoT and control it through web apps.
• Use WebGL to create a more user-friendly interface for the technicians and doctors who review the processed results.
• Make the deployment free of downtime.

Thus, the solution that the team provided added business value to the product:

• The patients get their implants faster.
• The technicians' job has become easier.
• The costs of logistics and software are reduced, and so the service price can be reduced.
• The number of patients can be increased.
• The revenue is increased.

I am an engineer! Why should I care?

As a developer, you may think that value is out of your scope since it's about business, not about programming; thus, it should be the responsibility of product managers, project managers, business analysts, and other professionals.

"Give me tickets, spell out the requirements and methodology, cut down the meeting time, and I'll deliver a great result,"—you might say. It does ring true. If the team comprises all those roles, the engineer might not need to bother. However, if the project team is small, we act as engineers and developers. When the client explains the idea, we use our knowledge of technology to help the client improve the product.

Imagine a school where first-graders and school-leavers solve a math problem. Their problems have different levels of difficulty, but both groups can solve their problems correctly. How can we check the result? It's easy in Math: if the solution corresponds to the givens—the answer is correct. It won't matter if the triangle the students drew while solving the problem was neat, what methodology they used, and how many brainstorming sessions they had with classmates.

In programming, the product solves business problems only if it adds business value to the end product. For instance, if it reduces the number of errors, speeds up the deployment process, updates libraries, boosts the functionality, moves files from desktop to the cloud, and so on. It doesn't matter what programming language is used and how many meetings are held if the end result doesn't meet the requirements. Even if we have developed perfect product parts that do not integrate well—what we've done cannot be called a solution.

Types of business values

Getting from Math problems to business problems, let's consider what business values there are.

Commercial value—what you can sell. For example:

• An updated version of the software suite the user needs to buy to access.
• New subscription plans that bring in more users if they can choose between different plans.
• Reduced operational costs.
• An opportunity to generate a personalized invoice for the used services (the way Amazon does it).

How can you check if this value is added? Ask yourself: How much profit will the functionality generate for the client?

Market value—how the new feature will affect the product on the market. Will the product become the next Uber that will blow the niche, so to speak? The market value may lie in anything: ideas, brilliant realization, an extension of the platforms used for the product.

Your control question: How many new users will the improvement win?

Efficiency value is all about reducing errors and boosting speed through automation, deployment acceleration, and so on. These things may not be obvious if miscommunicated, so it might be hard to convince the client to invest in them.

Your control question: How much time or money will the new or improved functionality save?

Customer value—whether your solution retains the existing customers.

Your control question: What are the chances that customers will stay if we implement these changes? And vice versa: what are the chances that they will leave if we don't?

Future value—the changes that do not affect the product right now but will help it maintain the leading market position in the future. For example, if the change will make the product work faster, solve arising issues, and be interesting to the user in a year or two. It is similar to the efficiency value; the difference is that we only anticipate the upcoming result rather than know it for sure.

Your control question: How much money will it save in the future?

Caring for business value ≠ writing bad code

I hope it's become clearer by now what to take into account when working on a product. However, I want to emphasize that adding business value does not mean we do not need to care about the code quality. Keep business value in focus but also ensure that your code is clean and well-structured. The more automated tests you use, the better the code is compiled, the more relevant approaches are used—the better the solution will be.

So, no way does business value deny hard skills; rather, it helps channel them correctly.

How does business value correlate with the key development concepts and principles?

1. Both Agile and Waterfall methodologies have a place for business value.
2. Acceptance criteria not only imply business value but may even codify and formalize it. That is, acceptance criteria may include the points that can help define business value.
3. Both functional and nonfunctional requirements contain business values. Tickets, stories, and epics are development details. Business value helps to see the whole picture and ensure that you do not end up doing something the user does not need.

What can go wrong?

If the whole thing may seem easy so far, there are a few flies in the ointment. I'll turn to potential problems you may face with value and give you ammunition.

Risk one—increased costs that the business may not be willing to pay. To add value, you first need to discuss the suggested solution and then implement it, which extends the development time.

Risk two—you might drown in the meeting culture. When meetings are held for the sake of meetings, people have to sit through hours of information they don't understand. The more meetings there are, the less time is left for coding. Do we underdeliver? Let's talk about it!

Risk three—the stakeholders have a different understanding of what will add business value. In this case, each stakeholder will try to get their way, leaving the developer wonder what task to do next.

And lastly, business values change. Their validity needs constant check-ups, which takes us back to the meeting culture.

What shall I do?

So, what does a developer need to do to provide business with code and value?

1. Don't start coding before you are sure you understand the task clearly.
   Do you know that warm feeling when you see a task you know how to solve it? And then, when you are knee-deep in work, you realize you haven't asked enough questions, you don't know the end goal, or you find a similar functionality that fits the task.
2. Ask the people who set tasks as many clarifying questions as you can.
   From the business value perspective, we can abandon the "What do I need to do?" question and ask "What solution will benefit the user?" instead. It may turn out that the tasks the client has set need changing, and the scope may either increase or decrease.
3. Think of as many test cases that cover business value as you can rather than simply focusing on the tests for your code.
4. Textualize your code before you plunge into optimizing it.
5. Now you are good to start implementing the solution.

How to check if you've added value?

You may use the Types of business values section as a checklist. However, there's a shortcut too. Think if your end user will thank you after using the product. If the answer is "Yes," congrats! You've done a fantastic job! If the answer is "No," all the project achievements do not matter much. The job is not done, and it can't be released to the user.

And the winners are…

Wrapping it up, let's see who benefits from our value approach.

The user gets the product that works faster, better, smarter, or does the things it never did before.

The client sells your cool product easier and increases the revenue. It's a win-win: the client gets the solution and learns about innovative approaches he has not even considered before from a proactive team.

The contractor company gets satisfied clients willing to collaborate with someone who increases their revenue again.

The team of the contractor company decreases the chances of delivering an unsuccessful project. Besides, knowing about business value turns your job from plain coding to adding value, which boosts the team's morale. What else does a developer need but to see that the job is useful.

The developer gets to speak the same language as the client. This, together with technical expertise and knowledge of development trends, makes the developer invaluable to the client and the market. When you are asked to tell about your projects during interviews, and you can tell about services, components, databases, and interfaces—that's good. When you also tell about the value your job added—your own value shoots up. As an interviewer, I always pay attention to that aspect, and I know that others do too.

To sum up

Adding business value is not a sure cure to all the project issues, but it definitely helps to see your tasks in a new light. Ask more clarifying questions to avoid miscommunication pitfalls, and in time, you'll get to the level where you define the app architecture yourself. And your experience with business value will come in very handy.

Thank you for reading. I hope this article will spotlight new dimensions of your job and open new career avenues.

If you'd like to dig deeper, here are the articles that helped me get to grips with the topic: "What Is This Thing Called "Value"?" (Medium), "How to Get a Job Offer from Google: A Getting Ready Guide" (DOU.ua).