In the realm of evidence-based management, we often discuss various areas of focus, but one key value area that frequently slips under the radar is unrealised value. This aspect is just as crucial as the others, yet it tends to be overlooked by many organisations and teams. Today, I want to delve into what unrealised value means and why it’s essential for your product development strategy.
Understanding Unrealised Value
Unrealised value refers to features that you either haven’t developed yet or don’t even know you need. This could be due to a lack of market insight or simply because the features are still on the drawing board. The market—whether external customers or internal stakeholders—drives the need for these features.
- External Market: If your product is aimed at the general public, your market is outside your organisation.
- Internal Market: If you’re delivering solutions within your organisation, your market is your colleagues and internal users.
The crux of the matter is that unrealised value is about understanding what your users truly need. It’s not enough to assume that a feature will be valuable; actual value only materialises when you present it to real users. Until then, everything is merely an assumption.
The Importance of Market Understanding
Let’s consider a practical analogy: renovating a house. If you’re targeting a family of four, you wouldn’t want to concrete over the garden. Instead, you’d want a spacious lawn for the kids to play on. Conversely, if your target market is a childless couple, a low-maintenance garden would be more appealing.
This principle applies to product development as well. You need to ask yourself:
- Who will use our product?
- What do they want now, and what might they want in the future?
- How can we attract new users to maximise our product’s value?
The more users your product serves, the greater its value—whether through a commercial relationship or internal utility.
Hypothesis-Driven Development
I firmly believe in hypothesis-driven practices in product management. When you have a belief that a feature will add value, it’s essential to break it down into a hypothesis. For instance, if you think a new feature will attract more users, quantify that belief:
- Hypothesis: If we build this feature, we expect a 10% increase in users.
- Validation: What’s the smallest version of this feature we can create to test our hypothesis?
This approach allows you to validate your assumptions without committing extensive resources upfront.
A Case Study: Dropbox
A classic example of this is Dropbox. When the founder sought investment, he faced scepticism about whether anyone would want the product. To prove demand, he created a simple video showcasing the features and set up a landing page for interested users to submit their email addresses. The result? Millions of sign-ups, which he used as evidence to secure funding.
This illustrates the power of validating hypotheses before fully developing a product. You can test market interest without building the entire solution.
The Role of Deployment Frequency
Once your product is live, the speed at which you deploy updates is critical. Your deployment frequency dictates the minimum length of your feedback loop. For example, if you deploy every two weeks, you can’t gather feedback any faster than that.
- Feedback Loop: If you deploy twice in a month, your feedback loop could take up to four weeks to complete.
- Continuous Deployment: If you deploy continuously, you can significantly shorten this feedback loop, allowing for quicker adjustments based on user feedback.
Conclusion
In summary, unrealised value is a vital component of product development that deserves your attention. By understanding your market, validating your assumptions through hypothesis-driven practices, and optimising your deployment frequency, you can unlock the full potential of your product. Remember, the goal is to serve your users effectively, and that requires a commitment to continuous learning and adaptation.
Let’s not forget that the journey to realising value is ongoing. By staying attuned to your users and their needs, you can ensure that your product remains relevant and valuable in an ever-changing landscape.
In evidence-based management, we talk about multiple areas of focus. We talk about multiple key value areas, and one of those key value areas which is really important and most organizations and teams forget about is unrealized value. Right, they’re just as important. All four of them are as important as each other, but because this is the one that’s often forgotten about, unrealized value.
Unrealized value is features you don’t have, maybe features you know you need to have but you haven’t shipped yet. Maybe there’s features that you don’t know you should have, and all of those things are driven by the market. Right? And when I’m talking about market, you could picture in your head one of two things. If you deliver to customers, general public, it’s a commercial product, then your market might be external to your organization. If you deliver inside of your organization, then the market is inside of your organization. Right? So that’s what I mean when I say market. The driving forces for what your product needs to do, right? Whether you fit the market, people are going to use it. People are using the features. People are engaging with the things that you’re doing. People care about what you’re building. Right? That’s all part of that market story.
So, unrealized value means that you don’t know. You don’t know necessarily what you need to build, or even if you think you know what you need to build, it’s based on assumptions, and you don’t know what’s actually going to provide market value. Right? Actual value only happens when you get it in front of real users. Everything before that is an assumption. We can try and validate our assumptions. We can try and weed out bad assumptions, right? Bad features, things that we don’t think, “Oh yeah, we’ve done it on paper and it doesn’t look like it’s going to work.” But the reality is that until you get something that you think is going to provide value in front of real users, you don’t know whether it’s going to provide value.
Like if you were renovating a house, right? Are people actually going to buy it? And are they actually going to pay the price that you think they’re going to pay? If you have a keen understanding of what people are looking for, if you have a keen understanding of the market, if you have a keen understanding, yeah, of who’s going to turn up and potential buyers, then you can tailor the build of your product towards those potential buyers and make it more appealing for them rather than less appealing. Right? So if you’re renovating a house and you’re going for a family of four, right? Two kids, don’t concrete over the garden, right? Because the kids want to play in the grass. The kids want to kick a ball about. A large back garden with lots of grass looks appealing to a family of four. Right? But if you’ve got a one-person house with a garden, you want that, or a couple, right? A childless couple, you want that to be as easy maintenance as possible because they might want to sit out in it, but they don’t want to spend a lot of time maintaining it.
Those are the things that you’re thinking about with your products as well. Who’s going to be using our products? What do they want to do now? What do they want to do in the future? How can we get different users? Who could we get in so that there’s more people using our product? What features do we have to build to bring in net new users to our systems in order to maximize our value? Our product provides more value if it serves more users, either through a commercial relationship or through an internal providing value inside of the organization. So that unrealized value piece is that story and how we engage with it. We don’t know whether things are going to be successful even if we have the coolest idea ever.
So we want to break that down. I’m a firm believer in hypothesis-driven practices from a product management perspective. You have a belief, right, that a feature’s going to add value to the product. As a product manager, as a leader in the business, as a CEO, right? I want this feature, but we need to break that down. What’s your hypothesis? Right? If we build this feature, what do you think is going to happen? We’re going to have more users. Okay, well, how many more users do you think you’re going to have? Right? You turn it into a hypothesis. If we build this feature, we think we’ll get 10% more users. Okay, what’s the smallest thing from this feature that we can build in order to start validating that hypothesis? Well, we think this is the most valuable piece. Well, let’s build that and see how many users we get. How many new users come to our platform because we built this smaller thing? And maybe that’s only a few days’ work to build that smaller thing to test the market, to test the hypothesis.
What was the great example of this, which is a little bit orthogonal, is Dropbox. Right? When Dropbox, somebody came up with the idea for Dropbox. I can’t remember the dude’s name, but he came up with the idea for Dropbox. But his investors didn’t believe that anybody would want that, so he couldn’t get investors. Nobody would invest in his product. So he needed to demonstrate that people wanted to buy his product. So they created a pretty cool video. It’s probably not pretty cool now, but Dropbox is pretty old. A pretty cool video that demonstrated the features in a selling video. And they put up the video on a website with a text box for your email address. Put your email address in here if you’re interested in this product. And then they spent some money marketing it, and they got millions of signatures. Millions of people put in their email address, and that was the evidence that they used to go to the investors to get them to invest. And they got their funding to start building the product.
That’s an example of we have an assumption. We think people want this product. We’re going to create a hypothesis. We’re going to get lots of, that’s my crappy hypothesis. We’re going to get lots of people if we build this product. And then how do we test? Well, here’s one way to test whether people are interested in it, and we didn’t even have to build the product to do it. So validating those hypotheses at every stage, and that requires, especially once you build your product and you’re starting to add new features, you’re going to be using feature flags. You’re going to be using continuous delivery to get those features in front of real users as quickly as possible to gather feedback, gather telemetry on whether and how people are using those products.
So your deployment frequency is a huge part of that story because that is the minimum length your feedback loop can be. Right? So if you deploy once every two weeks, you can’t get feedback shorter than every two weeks. Right? You’re going to deploy to production at the end of the two weeks. You’ve then got to recognise telemetry, and then you’ve got to get it back into your story of delivery. Usually, it’s twice your deployment frequency for most things. It’s twice your deployment frequency. So if you do two deployments, your feedback loop is four weeks. Getting into production, customer feedback, analyse it, get it into your backlog. Product team picks it up. The shortest that can really realistically be is twice your frequency. So if you’re deploying to production continuously, if every commit ends up in production, it minimizes that part of the feedback loop, and everything else is people. And people are much easier to figure out how do we get this done more quickly than systems because systems take a lot of work for that.
