Defining Business Value —
Questions answered in this chapter
- What is business value?
- Why is it important for developers?
- How does technology affect the business world?
Our Best Interest
Before we dive in, let's take a look at why exactly should you care about this topic. It's general business wisdom to be customer centric. Why don't we start with them? Well, just between you and me, developer-to-developer, our best interest is to have a good relationship with our employers first and foremost. No user complaint or code quality issue will affect your paycheck as long as the company is happy with you. If you work as a business owner, freelancer or consultant this reasoning should go a little differently, but the ideas we will arrive at are the same so please stick with me. At any sensible enterprise the focus is of course, on the customers and how to help them, but from our perspective that's a derived value. We do that to serve the interests of the company. Unless you are a really mission driven individual, our primary goal is to make our employers / clients happy. So first we need to understand what they consider valuable and focus on delivering that.
Do It Our Way
During my career, I have heard the term “business value” thrown around by management as the holy grail of software development. I’m quite sure most of you have also heard it many times, or even got sick of it already. I have never met anyone who could specify what does it exactly mean for us. If you search for it online, it’s hard to come by anything that is practical for a developer. Even Wikipedia says there’s no consensus on its meaning. (Although there are some good ideas in the article.) But I wanted to start with the business part and define the most fundamental goals so I decided to get the job done myself. The 1st axiom states our task is to solve human problems. By describing business value, we will identify the first big family of problems.
Let’s start with the basics. What is the ultimate goal of a company? In the best scenario, they have a mission and a way to make it financially viable. In the worst, the stakeholders want to get filthy rich, found a market gap and made up a mission statement for show. Whichever is the case, they all have to have an idea of success in order to operate. A mental picture of how the bright future looks for them. Or a vision document filled with statistics, compiled by a consultant firm and ratified by the board of directors. The point is, unless things go horribly south, a company knows the direction and the destination they are heading to. Ultimately, our work is just one of the parts in making that happen. This is why I believe it’s very practical to define business value as whatever that helps them get there.
Business value is anything that makes the company more successful.
That sounds nice, but doesn’t mean much, unless we really get to know the business and honestly speaking, if we want to have the highest chance to make beneficial decisions, we absolutely need to understand what is success for the company/project we work at. I wanted to identify what’s the bare minimum a developer needs to know about it in order to align tech with any business goal. It turned out to be not much! We don’t need to earn an MBA degree, only basic business literacy will do. In fact, it’s so little, all the necessary knowledge fits into a single chapter, that’s Chapter 3. After learning it, you will never feel lost again when talking about business value. Later in the book, we will connect specific technology properties and developer actions with the kinds of business values they provide. That’s all you need to tell what matches the financial needs of a project and having that ability is a game changer! It’s a rare skill among software engineers, yet crucial for the success of the companies. I will also provide a simple, developer-centric approach to define the business needs of an organization in Guide 1.
Now that you saw the highest level view of our relationship with the business world, it’s time to go one level deeper. Success is a great goal, but not specific enough to be useful in itself. This is where things can get complicated in real life. We need to have a list of company objectives to identify the appropriate technical solutions. However, if an organization doesn’t have a clear definition of their own success, it’s really hard to do a good job in making them succeed. For the sake of our own good, I’m not covering how to solve such issues. To better understand what success is, we are going to talk money. Company vision and mission statements are important and we will get to them eventually but because they mostly concern outcomes in the life of people not outcomes in the life of the company that will happen later. The business values we are interested in are measured in financial metrics and the reality is that many enterprises care much more about these than anything user related. We need to see how our decisions play into reaching their financial goals. It was much harder to identify the most basic elements of this area than I initially thought, but they are so simple you won’t have the slightest issue with understanding them.
The 4 pillars of business value
If you run a profit oriented company and your goal is to maximize the gains, the 4 most fundamental actions you want to take are:
- Increase revenue
- Protect revenue
- Reduce costs
- Avoid costs
While this list looks basic on the surface, it will become a powerful system that has a huge depth below the top level. It will also offer tremendous help to us! Why? Because these are the 4 fundamental problems of the business we are supposed to solve. Knowing how tech can do that is key to become effective at our real jobs. We will use this as an elementary building block of the Full Context evaluation process to serve as the start or finish line, depending on whether you are looking for a tool to deliver given results or evaluating the potential benefits of adoption.
To memorize them, I found the following acronym incredibly helpful:
RIP CAR as in Revenue: Increase, Protect - Costs: Avoid, Reduce.
To reach the other end of the spectrum, we need to get familiar with every aspect of software that interacts with the business world. Could you define all of them?
The Two Components Of Commercial Software
From the financial point of view, the software solutions we offer have two components. The product and the service. All of you know what the product is, but because I have a pedantic part, let me be precise: it’s the systems / programs we create or contribute to creating. The service is less well understood. Instead of coming up with definitions, the details below will tell you what it is in our case. You will see that even off-the-shelf software and open source projects have service aspects. Good tech decisions maximize the business value delivered by both the product and the service. That’s why we should never ignore the consequence of a choice in either area. Let’s do an overview of both components. In later chapters, we will discover all their nitty-gritty details and the ways we have to influence them.
The product
This is the software being sold. Sometimes it’s a combined package including hardware, the infrastructure needed to operate the solution, accompanying documentation, training, integration with other systems and other benefits. It has 2 key aspects:
Functionality: It’s what the people are using the software for. The solutions it provides to the real-life problems. Essentially, this is not a software engineering concern. We can hold it back from its full potential with a bad implementation but unless you own the product, it’s not (mainly) our job to decide what the applications should do. I’m sure I don’t have to explain how this affects the financial performance of a software product.
User experience: The emotional impressions experienced while using the product. This plays a huge part in the success of any commercial projects. When choosing between solutions with otherwise matching characteristics, usually the one with better UX will be the most attractive for potential customers. We have a lot to do with this, even if our work never affects the UI. I will cover this in detail in Chapter 6.
The service
These are mostly properties of the processes used by the solution provider in developing and maintaining the product. It has 5 key aspects. (You can toggle the points for details)
Release performance: This is a composite metric of two opposing concerns that need to be balanced.
- The frequency of releases. How often the software gets refined, patched, extended and delivered to the users. It's closely related to the speed and granularity of development and CI/CD adoption.
- The amount of released value. How impactful benefits do a new version bring to the table for the users, the business and the organization. Because we can also deliver hindrances like bugs or unnecessary features, it’s not always a positive measure. This is related to quality controls, both in planning and implementation.
Because ensuring value is created and delivered slows down the development speed, these are opposing forces. They are individually important, with different related business values as people both like to get good updates and get them frequently.
Support: This has various aspects, many of them are unrelated to tech which I will skip here.
- How easy it is for the customers to get help with their product related issues.
- How eager the company is to solve the customer's problem after initial purchase.
- The longevity of updates and patches.
- Help with integrating the product and the other tools the customer uses.
- Adherence to SLA or other contractual obligations
We can be involved to different degrees in providing these services, depending on our role and the size of the company we work for. Customers like having help available, and issues fixed for them. It helps a lot to create a positive image of the company.
Price: This has two important considerations for any customer: The total cost of owning the software and the pricing model.
It's a compound of many factors and our decisions are concerned only with a couple of them like the costs of labor affected by the speed of project completion, the price of the skills needed on the project, and the ease of future maintenance.
Community: Online and offline platforms facilitated by the company for experience and knowledge sharing, community support, etc...
This is a part we rarely engage in unless you work in the Game development industry, but it can improve the relationship between the users and creator of a product in any field and provides lots of financial benefits.
Feedback: Opportunity for users to give their opinions, request changes, see the updates made in response, etc...
This is again an area we usually interact with only indirectly, but can be a game changer for companies to improve their products.
Chapter 6 will show all the practical ways you as a developer have to influence these elements. I will also show you the exact related business values so you will be able to evaluate where to put more or less effort in order to align with a company's strategy.
I like to call this list the User API, because it contains the complete set of tools at our disposal to impact their lives. It’s another fundamental building block of the Full Context approach, as these are our options to solve the problems of the customers. Knowing all that you can do for them is an important step towards focusing on doing our real jobs well. Mastering their details is empowering. You will face new projects rarely - if ever - feeling unsure if your technical choices will lead to improved user satisfaction or not.
I came up with an acronym for these too. C-PUFFeRS. Like puffer fishes living in the sea. It's from: Community, Price, User experience, Functionality, Feedback, Release performance, Support. I know, it’s not too impressive, but I couldn’t make out anything more sensible. If you have a better idea, hit me up.
By now, we discussed the relevant high-level properties of the business environment and the different aspects of software interacting with it. To complete the overview of the full context, I will show you the rest of the tools we have to deliver value by inspecting the possible ways a technology change can affect our environment.
The First Level Of Change
This is the entry point of changes into the scene. There are 4 areas or parts of the software delivery landscape involved. The introduction or removal of any software technology will influence at least one of them, but usually all. We already saw 2 out of the 4:
- Product
- Service
- Development process
- Corporate matters
It's pretty simple, yet comprehensive. Let's do a breakdown of them.
Product & Service
I’m not going into the details for these two. It’s easy to see that technology changes will nearly always affect some of their parts.
Development process
This is the process of creating and delivering the solution, all steps included. We will go more in-depth a bit later. The point now is that whenever a technology change happens, it will obviously introduce changes in the process of creating the software.
Corporate matters
The remaining effects of changes that are not included in the first three all fall into this category. Meaning: schedule & budget, hiring, career development, management processes and more. The general theme is that they are not directly involved in the creation and delivery of the solution, but have an effect on the people and processes surrounding development.
As we make a technology choice, the effects immediately visible for us surface through the 1st level items. Here’s an everyday example.
Example: To improve the performance of our software product, the tech lead decides to use a new library. Because it’s low-level, complex and has a niece application, leadership decides to hire an expert (let’s call her Samantha) to spearhead the adoption. The product in question has been in development for 4 years by multiple teams. Introducing the codebase to Samantha in necessary detail took away most of the capacity of important members for two weeks. As she introduced the new tool to the project, she also taught its usage to the developers, so after a month, mostly everyone is comfortable to ship new features with it.
Let’s examine the first changes you might notice working on this project. Your team lead announces that a consultant is joining the department to improve the product. The plans for the next sprint have to be changed because a key team member is required for the onboarding. The product owner removes bugfixes from the scope and the developers are happy (including you…) because those are frustrating to deal with. Starting from the third week, there are some refactoring efforts going on to integrate a new library into the overall codebase. Samantha turns out to be quite nice to work with. There’s synergy between the parties. The effort plays out nicely. Application performance has improved. Thanks to that, some long-standing customer complaints go away, support tickets go closed. You get a one day training on how to use the tool with a fine company launch included. The senior engineers seem to like the library, so the rest of the teams get on board easily.
Life is good. 🍹😎
I’m sure you already spotted how the elements of the first level are involved. The application speedup affects the Product. Omitting the bugfixes changed the release performance, and the gone complaints are a pure example of what feedback is. Now you might also need to resolve production issues involving the library, which can affect the quality of support you provide. All of these are parts of the Service aspect. There are temporary changes in the Development process because of the missing members and the refactoring going on. There’s also a permanent one in the form of adopting the library by every team. The changes in the sprint plan, the budget reallocation for the consultant’s fee and, of course, introducing the whole idea to the management in the first place are all Corporate matters.
The Second Level Of Change
Going one step deeper means abstracting away from the concrete to the outcomes. What effects do the 1st level changes produce further down the line? Once you understand this, you will understand the heart of Full Context Software Development. The second level is the bridge between the technology and the business ends of the entire spectrum. That’s why it serves as the backbone of the decision making and evaluation process we will build. I had to spend quite a lot of time with gathering all possible effects and identifying the most general categories they belong to. The result was more than worth it. On the highest level, there are only 4 things affected by any tech decision:
- Customer experience
- Productivity
- Utilization
- Direct costs
- Business opportunities
This is again simple and comprehensive with much depth to unpack later. Now I want to give you an overview of each.
Customer experience
I will use CX to refer to it. One of the first things that came to my mind when researching this topic was how is it different from UX (User Experience)? Let’s address that quickly. UX is a subset of CX. While UX is concerned about the experience during the usage of the product, CX encompasses every point of connection with the customer. That means the collective experience of all the encounters between the business and them, including things like advertisements, sales activity, reviews, trial periods, product usage, support, repairs and much more. We will later analyze what are the interactions with this process for a developer through technical means. To get a very general sense of when this area is concerned, just try to see if a decision affects any part of the User API.
Productivity
The holy grail of tech decisions. This is the most common factor that everybody is always trying to improve. The new language, the new framework, the new library or the next version of them. Productivity gain is a good aim. The reason why it’s in the center of our attention, I believe, is that we developers can directly experience it. Of course, we are concerned about optimizing our performance or eliminating the hurdles of everyday work. These two are good examples of how to improve productivity. In general, it’s all about getting more bang for your buck, to achieve more with the same or even less effort. It’s very important to remember two specific attributes of productivity. It can create a better customer experience, and it always affects utilization. You will learn how in the next chapter. Try to keep in mind whenever we mention changes in productivity, those two areas will most likely be also affected.
Utilization
I’m not sure if this is really the case, but for the sake of consistency I will call this the holy grail of IT management. In my experience, managers really love to track this metric and our tech decisions can have significant effects here. Utilization is maximizing the gains from the existing resources, or getting the actual output of production closer to its highest optimal value. In software development, this mostly concerns the performance of employees and the IT infrastructure. Whenever a change in technology affects the number of people working on a project or the time it takes for individuals to complete their tasks, it has a utilization concern. Similarly, if it affects the usage of hardware or software resources or the costs of work, this effect is in play. Here’s a fun fact for you: According to a Harvard Business Review article, too high levels of utilization are actually hurting overall performance.
Direct costs
The most straightforward aspect. Technology changes nearly always have direct financial consequences like the cost of implementing them or they might take the form of service fees, the costs of purchasing new tools, licenses, etc… We are usually aware of these factors and easily take them into account while making decisions.
Business opportunities
This one is quite broad in effect and simple in definition. Technology can enable companies to gain new streams of revenue. The most common way is by simply making it possible to implement new products and services. Sometimes a new stream can transform even the business model of the company. This area is the least frequently touched by our choices because it’s core to the operation and structure of the enterprise or product.
Acronym incoming! This time it’s really simple. CPU-DB. Do I need to say more?
I also like to call this list the Financial API as this is the full set of factors we can influence through technology to improve the financial performance of software products.
It’s the purest tangible form of what we are actually supposed to care about and deliver with our work.
Let's continue our previous example. How does it translate to the second level?
Example: In the month after the go-live with the reactor, your manager reports that the number of new sign-ups has slightly increased, but the churn rate (# of lost users/time) also got higher. These are due to changes in the Customer experience. The long time users who were complaining about the slow speed of some functionalities started to recommend the app more. Also, the number of people who kept their subscription after the two-week trial period increased a bit thanks to the better UX. On the other hand some customers got fed up with the again delayed bug-fixes they were waiting for so long and abandoned your product in favor of a competitor.
For the time of the ramp up and training, the Productivity of the teams went down. They couldn’t deliver as much as usual. Some of the less experienced developers who relied on guidance from the seniors doing the onboarding got stuck on tasks for much longer, meaning their Utilization went down as well. However, this will get compensated for as implementing speed sensitive features will go much smoother in the future. It’s less of a pain to deal with now, that makes people more motivated to work on such items.
Bringing her on board and disrupting the usual flow of work had directly affected the Costs of development for a while that are offset by the long-term gains.
Samantha went to a gathering with some of her old time buddies and shared how she enjoyed the project at your workplace. One of them was just starting a software business and contacted your company if they can integrate with your system. Another team had to use a new library to deal with the protocol used by the other application. That way the lib has enabled a Business opportunity.
I'm sure by now you can clearly see, how these 5 categories cover everything tech can do to deliver business value. This is our toolbox.
Wrapping up
If you have a keen eye, you might have already spotted a very interesting property of everything we discussed so far. I only made this observation more than a half year into writing the book. Nothing in the first 2 chapters is unique to software! (That will be the case with the 3rd as well.) If you don’t believe me, go and take a look at the main points we made, while replacing the word “software” with “product” and “code” with “plan”. They don't translate perfectly, but it would only take a little effort to generalize all those ideas to apply to any kind of product, and the conclusions we made would still hold entirely true. To me, it’s actually a validation of their timeless and universal nature. Software is a product, from a high level point of view, creating it has the same concerns as creating anything else. That’s why I believe:
what we identified are the basic principles of product development in general.
I didn’t aim at finding something so wide in scope. My focus was on software all along, but as the topics unfolded, I got more confident in that these general ideas are crucial to understand the full context of our work and to make tech decisions that deliver the business value expected of them. Knowing these principles is hugely beneficial in and of itself, but the real value of the book comes from applying them to our field. We will do just that through the majority of the chapters, exploring the details and connecting everything to what we usually do while developing software.
System Overview
Please keep in mind these images contain exaggerations and jokes but the points they make are still valid. You will know when not. (For now, please open them in a new tab to see in full size, under development)
You After Finishing The Book
The Problem We Are Tackling
The Solution We Create
