Business needs in software

sketchesRecently I’ve had a great opportunity at DNV GL to learn more about how the business works, and crucially, where the project briefs come from that tell us software types what to pursue.

As a solid UX/agile team, we’re pretty good today (even if I do say so myself) at getting to know our users, establishing what’s of real value to them and delivering that with our software. We have a good handle these days on what’s technically feasible as well and thread these considerations through our process. There is however, a third factor that doesn’t always get as much of our attention as it perhaps should – that of business value. 

Lately our product owners have been discussing long-term visions for each of our software products with senior management. Why? To help decide where the business should invest software funding over the coming few years. Naturally, being the guy who best understands our users and who spends the most time thinking about future developments, I’ve been helping, first in helping product owners to establish product visions and roadmaps, and then presenting to management how these plans will deliver user value and be developed in a cost-effective way. Additionally, I’ve had an opportunity to introduce people in influential positions to UX and agile and present our own strategy for how we might make better use of design as an organisation.

These meetings ran over a couple of days and I was privileged to be included in something which gave me insight into the decision-making process that determines our project briefs. The software department,  it occurred to me, could still stand to ask ourselves more often how what we’re doing will deliver value to our business.

Now day-to-day, us software types don’t often find ourselves talking about return on investment or profit – business goals are often seen as less worthy than making great products for people. I, for one am a great believer in the benefits of good design, regularly motivated by disdain for bad user experiences and helped by the noble goal of using design to improve the world’s energy sources. Our team tends to be given steer from above on which products the company will support; and with message received we will get to work, our assumption being that each project was chosen with a solid business case behind it. The past few weeks have invited us to think beyond our project briefs, asking bigger questions about why the project exists in the first place and what else the right product has to do when we deliver it.

Isn’t this a distraction, you might say? Not our job? Well I disagree. We’re here to deliver a successful product, and along with development and design considerations, the business case is critical to our success – that might be the product’s revenue stream, its position in the market landscape, the value it brings to our brand, or how it helps the company pursue its own ambitions, such as the promotion of solar energy. Ultimately unless our software make good business sense, it will not survive long enough to have any real impact.

Several years ago, before we – as a team – we got a handle on using design well, the main voice in the room was that of the developer – what is technically feasible, what we can build and what will function well. We’ve spent the last two years ensuring the voice of the user is heard too by bringing UX research and design into the fold. There is a third voice too of course, and that is the business, which needs to be profitable and make smart investments so we can keep doing what we do. Perhaps for our team the next step is to take ownership of business value as well as user value, understanding more of the reasons behind our project briefs and building these considerations into the agile process too to ensure we’ve got all bases covered. I for one can only see it helping us deliver on the things that are closest to our hearts – happier users and greener energy sources.