One thing I’m coming up against more and more in my day to day work, is understanding the value of things. Understanding value is a cornerstone of executing on any sort of vision – whether it’s product vision, department vision or corporate vision.
A key component of my job is understanding where time should be spent and what ideas should be executed on. These ideas could be new features to add to a product, new deliverables for a service, or an item for business improvement. With all these different areas and ideas, how do you decide what to spend time on and when to spend that time? Or even whether an idea is worth executing on? When considering these ideas, I have to consider the value of each idea.
So, what is value? The Oxford Dictionary defines value as “The regard that something is held to deserve; the importance, worth, or usefulness of something.” In my case, “something” refers to the ideas that I’m considering – but how does understanding the value help me?
Imagine that I’m looking to buy a new car. I could go down to the local dealer and walk through the yard, and just pick a random one. But is it the right car? Does it meet my needs? To understand whether the car I’ve chosen meets my needs, I need to answer a few key questions. Why do I want a car? What does a car do for me? What features should the car have, and why do I want those features? By considering these questions, I’m understanding what value a car provides to my life. And by understanding the value of what I’m looking for, I can then figure out whether the car I’m looking at will align with the value I require.
The same goes for business. When I’m considering a new idea, I need to understand the value. Does a customer want the feature, and what are they trying to get out of it? Does it improve the speed and quality to which an employee can complete their job, and what’s the cost (time/money) of achieving that? It’s also important to make sure that I’m not confusing my value with someone else’s value. Take a service that shows metrics on test case execution as an example. I might get value out of knowing the intricate details of how the tests ran – which ones passed vs failed, how long they all took, what our code coverage is like. An executive, on the other hand, is likely to only care about the fact that they’ve all passed before we shipped the code. Therefore I need to make sure when I’m building this service, that I’m building in features that provide value to the people using it.
So I need to understand what different people may derive different value from an idea, and how to execute on that value. There’s no point me spending time implementing a feature to a whole product set, if there’s no target that will find value from that feature. On the same page, if there’s an idea that will take a few weeks to execute but reduces risk on deployments – that’s likely an idea worth pursuing.
But I can’t assume that the value is always going to stay the same. A feature implemented 2 years ago for a particular target audience, may not be a feature that provides value any more. Perhaps the solution or requirements have changed, or the purpose or impact of a project has evolved. Either way, I need to be considering this change when reviewing the value of features – it would be ignorant to work on delivering the same set of features that no longer provides value. This is something I had to execute on recently – revisiting the reason for a solution that had grown organically over a few years, to ensure what it was designed to do was still providing value.
“Price Is What You Pay, Value Is What You Get”. (Warren Buffett) For people finding themselves in the same boat as me, keep digging to find the value. Don’t just understand what you’re doing, but why you’re doing it. Understand where the value lies and you’ll be able to better see where your focus needs to go.