On the surface, the crux of product management seems simple enough: what should we be building right now?

Of course, anyone who’s had to answer this question knows it’s much easier asked than to come up with a confident response. As software engineers, there are a hundred things we want to do with our code at any given time. Some of them are features that we think the users are going to love. Others are things that have been a pain to us – like a bug that we have to work around daily or a database query we need to manually run on a weekly basis. Most of the time, these are things we just think would be cool to build.

Just because we want to build something though, doesn’t mean we should.

This has been an issue that has bugged us for the last few years at my work with Synacy, and we’ve tried a lot of things to address it – gut feel (duh), RICE (reach, impact, confidence and effort) score, more stakeholder involvement, less stakeholder involvement – and they’ve all helped one way or the other. Unfortunately, however, the outcomes have not yet quite met our own expectations and a lot of the work we do has ended up getting shelved (at least for the meantime).

This year, we’ve decided to (yet again) try something new, and our new and (hopefully) improved approach started with just sitting down to really understand the value of a software project.

Defining “value”

Value is one of those words that gets thrown around a lot in the business world, but no one really has a strong definition for. And the reason it’s really difficult to explain is because it doesn’t actually mean any one thing. It means different things to different people and in different contexts (i.e. time, conditions, etc.). A 2022 calendar, for example, would have been a lot more valuable to most people last December than today. On the other hand, if it’s of the collectible kind, someone (not everyone) would probably pay the same or even more for it regardless of the timing.

But while value varies from person to person and from situation to situation, it is nonetheless essential for an organization to have a common definition of it. And perhaps more importantly, it’s important to keep this definition updated – lest you end up trying to catch a bus that has already left.

Value should be the common language that drives priority and the feasibility of all the work we do – regardless of whether it came from the sales team, an end-of-life notice for a library we are using, or news of some feature our competitor just released.

Now I’m not gonna tell you what value should be in your company, but I’m happy to share my own framework which we are now trying out at Synacy, and it revolves around four pillars – revenues, savings, learning, and mission. Let me get into each of these in a bit more detail.

Revenues and Savings

I’ve recently completed a financial management class for my MBA, and at the very beginning, we learned that the only goal of financial management is to “maximize shareholder value”. That means, decisions are to be made based on how much more cash it will add to the company coffers in the future.

Cash is measurable. If you want to get into meaningful numbers, there’s none better than the cash expected to come in (or prevented from going out) as a result of the work. Describing the value of a project this way, if at all possible, makes it very easy to weigh against others.

The reality in the software business, however, is that it’s difficult to come up with a confident cash value for most of the things we do. It may not be very practical then to depend purely on financial terms to determine the value of a project. Which brings us to the second point…

Learning

Lean Startup calls it innovation accounting. Most of the work we do in the software business actually intends to validate assumptions we have about the business model. Innovation accounting makes it possible to pursue and measure this.

You could measure it as simply as number of users onboarded. Taking it further, there are probably many more metrics that are specific to the business you’re in. The idea is to find out what questions you currently have and how those questions might be answered. If a project you have in mind contributes to getting those answers, that’s value.

Granted, these numbers are not directly comparable to revenues and savings. In fact, a cost-benefit analysis may not be straightforwardly possible when the benefit is in a more abstract number like number of users. But that’s a limitation we have to accept. The solution to that conundrum is simple, as Lean Startup also poses – if your goal is learning, just keep the cost of it low by doing small, cheap experiments.

Mission

While money allows a business to exist and learning allows it to grow, its mission is the meaning of its existence. On that note, there is value to pursuing something – even if it bears no financial benefit (or perhaps even a negative financial effect) and even if we won’t have much to learn from it – if it contributes to fulfilling the organization’s purpose.

That said, this is something that may fit very well with Synacy as a mission-driven organization, but perhaps not as easily relatable to some organizations where there may not be as much a focus on this. If your organization has a clear purpose, however, you should take on projects that contribute to that, if only to further your mission.

Ultimately, a mission-driven company that serves a worthwhile purpose will almost invariably convert loyal customers and more revenues in due time.

Now that you know all this…

Value is just one part of the equation of priority. There are modifiers like the assumptions we make in coming up with the value and the risk that we are completely off with our bet. And on the other end of the equation, there is the cost of the effort itself, which may or may not be a fair price to pay for the value we get. But that’s a story for another blog.

Nonetheless, starting off with understanding the value we are trying to create is already a large part of the journey. You may just find that a lot of the cool things you wanted to build don’t make any sense to build at all regardless of what it costs.