Identifying sources of value as business objectives

The balancing act between buyers and users

Designing and building software is a balancing act. We're always balancing the desires of the user of the software against the desires of the business who paid for the software to be built.

The person using the software generally falls into two categories: those who opt to use the software, and those compelled to use the software - usually because it's part of their job description. Either type of person may not mind if a business benefits from their use, but they have their own goals to meet and problems to solve that are likely not in perfect alignment with the business who paid for the software to be built.

The business paying for the software is generally concerned that their investment is well spent. While user satisfaction is part of that concern, user satisfaction alone can't motivate the outlay of cold hard cash to build the software.

When the person using the software actually laid down cash to purchase it, she'll face the same balancing act. She must balance the needs that motivate the use of the software with the cost of the software and the day-to-day experience they have while using it.

The inconvenient truth – software must be used to deliver value

We want value from the money we spend to buy or build software. We'll focus in identifying the features of software we could build that will give us the most value. And it may seem tempting to focus only on the objectives that the business paying for the software. But, for the software to actually earn the speculated value, not only will it need to be delivered, it will need to be used.

There are some instances of commercial "shelf-ware" - software built, delivered, and sold that isn't actually used. And in truth the business paying for the software earned revenue when it was sold. But that's a rare circumstance likely to be remedied soon by the customer who realizes they didn't get value for their investment.

Too many choices

Within any organization with the ambition to build a product, there are likely lots of possible benefits for doing so. If a field of business stakeholders is making strategic decisions for the product, they may all have favorite sources of value for the product. It may be tempting to leave the discussion there, to simply discuss and understand what those sources are, and take them into account when planning and designing software to extract that value.

But invariably we'll need to make decisions about what to design and build first. This is where sources of value compete and where compromise, addressing all sources, often results in delayed realization of value for any one source. If we do intend to prioritize, then it's important we first understand our sources of value and prioritize those.

Identify simple measurable objectives

We'll call these identified sources of value our Business Goals. And, if we're to understand if we're making progress towards those goals, we'll need a way to measure that progress. Finally, if we're juggling a number of these goals at any given time, we'll need a model that represents all of them, and their relative priority. The Measurable business goal model model holds this information and can be built collaboratively.

Identify simple financial drivers

Ultimately, in most organizations, driving towards business goals should ultimately have impact on the bottom line of the organization. The software we build should be helping us to increase revenue, reduce costs, or both.

If the specific goals of the software aren't easy to identify, it often helps to look more directly at the sources of revenue and cost relevant to a potential software solution. This can be done collaboratively using a simple financial modeling work session.

Understanding sources of revenue and expense may help quantify existing business objectives, as well as identify additional objectives.

Balancing value for builders and buyers

If you're in the business of building software to be sold commercially, your highest order objective may be simple: sell more software. You might sharpen your objectives by identifying new customer segments you could market to, and new features that may help your organization sell to those new segments. It's important to understand that your customers may be, or should be, determining what their own business objectives are and how the purchase of your software helps them meet those objectives.

For customers, especially customers that are making a large purchase decision, construct the same business goal model on behalf of your customers. Better yet, create a partner user group composed of customers you wish to collaborate with and create a business goal model collaboratively with them.

Different types of customers will have different goals. When creating customer-centric goal models, create a separate goal model for each distinct customer segment. The goal model for a customer segment along with other information about your customer helps create a rich profile for your customer. Later on in the users section we'll discuss how to identify and profile types of users. Use a similar approach for your customers.

Use your customer's business goal model to help you better identify and prioritize objectives for your software.

Identifying and prioritizing objectives is your first and most important decision

Designing and building software is a series of dependent decisions. Identifying and prioritizing objectives might be your first, and is the most important decision. All subsequent decisions will be made to meet these objectives. Keeping these objectives concise, and easily understood and communicated will help keep subsequent decisions aligned and allow them to be validated against these objectives.

Further reading