Value is such a subjective thing that we will often be wrong, and there is no way around that wrongness. In order to minimise the wrongness and maximise the amount of value that we deliver we need to have a clear understanding of what our users need, how they are using the product, and validate our new value as soon as we can. Without validation we only have assumptions and assumptions can be dangerous.
As a start we can collect some qualitative data to validate some of our assumptions:
- Customer Satisfaction - is a key measure as it is an indication of the happiness of your users with the features that you currently have in your product.
- Product Usage - Its key to see just how much of our product is being used by our users. There is no point in trying to add features to areas that are not being used. Features are only valuable if they fulfil some need for users and the business and usage is a key indicator of value.
- Employee Satisfaction - is another key indicator. If our employees feel that they understand how their work contributes to the overall product vision then they will leverage that focus and understanding towards building a better product.
For additional ways to measuring value to enable improvement and agility check out The Evidence-Based Management Guide
Real-Users create real-feedback
The only way to validate our assumptions is to get our perceived value in front of some subset of real users and gather feedback. I want to also be 100% clear that the term “real-users” does not mean Staging or UAT; it means production. When you ask someone to test something they do not use it in the same way that they would if they were using it for real. Following a test-script is not a real user.
Releasing is the only way to deliver value
Without getting our increment in front of those real-users we also don’t have any value. Its effectively sitting on our shelf in the warehouse and is depreciating. What is the cost of delay for your feature? If you could get this value, this new business feature, into the hands of real users and make their lives easier how much money would you save? You cant save that money until users can actually use that feature.
A financial reason to release early
And speaking of depreciation all of the software that you are creating, these new features, are capital expenditure. Your finance department is able to offset capital expenditure, and indeed often experimental features, against your tax! However, you are only generally allowed to do that once your features are in production. if you can get a smaller capital expendature into production and start writing it down on a monthly basis early you can compound that write-down by the end of the year. This could be a masive saving for your organisation.
There is no place like production
My favourite quote is from Brian Harry, the product unit manager at Microsoft and technical fellow:
“There is no place like production”
-Brian Harry
No mater how much testing, UX discovery, and UAT, that you do there will always be more things that you discover once you get into production. It is just not possible to simulate a production environment. We are much more likely to be successful and create value by getting the smallest piece of value into production and validating that it is indeed as valuable as we thought.
Smart Classifications
Each classification [Concepts, Categories, & Tags] was assigned using AI-powered semantic analysis and scored across relevance, depth, and alignment. Final decisions? Still human. Always traceable. Hover to see how it applies.
What to read next
Without Delivery, There Is No Value
Value in software is only realised through delivery. Frequent releases validate assumptions, reduce risk, and enable rapid feedback, …
Unlocking Product Value: Why Real User Feedback is Your Best Asset
Real user feedback is essential in product development to validate assumptions, guide improvements, and ensure your product delivers real …
Unlocking Unrealised Value: The Key to Elevating Your Product Development Strategy
Explains how identifying and validating unrealised value, understanding user needs, and rapid feedback loops can enhance product development …
Why “Done” Only Counts When It’s Live: Moving Beyond Fake Finishes to Real Value in Software Delivery
Discover why “done” means live in production, not just code complete. Learn to deliver real value, close feedback loops, and drive outcomes …
The Importance of Delivering Working Software Every Iteration
Explains why delivering working software to users every iteration is vital in Agile, highlighting feedback, value, and practical steps for …
The Importance of Validation in Product Development: A Strategic Approach
Explains why validating product features is essential, highlighting hypothesis-driven development, data collection, and evidence-based …
Detecting agile theatre with real delivery signals
Why Most Companies Operating Models Fail in Dynamic Markets
A concise comparison of Predictive and Adaptive Operating Models, explaining why traditional structures fail in dynamic markets and how …
Don’t Manage Dependencies, Remove Them
Explains why dependencies are a sign of poor system design and outlines steps to eliminate them by aligning teams, clarifying ownership, and …
The Estimation Trap: How Tracking Accuracy Undermines Trust, Flow, and Value in Software Delivery
Tracking estimation accuracy in software delivery leads to mistrust, fear, and distorted behaviours. Focus on customer value, flow, and …
Flow of Value vs Flow of Work – Misnomer or Useful Shorthand?
Compares “flow of value” and “flow of work” in Kanban, explaining why only validated outcomes count as value and stressing the need for …
Why Outsourcing DevOps Fails, and How Real Engineering Excellence Starts With Your Team
Avoid DevOps vendor lock-in, discover how true engineering excellence starts with partnership, not outsourcing. Ready to transform your …
Why Most Companies Operating Models Fail in Dynamic Markets
A concise comparison of Predictive and Adaptive Operating Models, explaining why traditional structures fail in dynamic markets and how …
Don’t Manage Dependencies, Remove Them
Explains why dependencies are a sign of poor system design and outlines steps to eliminate them by aligning teams, clarifying ownership, and …
The Estimation Trap: How Tracking Accuracy Undermines Trust, Flow, and Value in Software Delivery
Tracking estimation accuracy in software delivery leads to mistrust, fear, and distorted behaviours. Focus on customer value, flow, and …
Kendall Guide - A System of Work for AI Adoption
Flow of Value vs Flow of Work – Misnomer or Useful Shorthand?
Compares “flow of value” and “flow of work” in Kanban, explaining why only validated outcomes count as value and stressing the need for …
Estimating Better in an Overloaded System Is a Poor Man’s Strategy
High work in progress (WIP) causes delays and unpredictability; improving estimates won’t help. Limiting WIP and focusing on flow is key to …
Why Most Companies Operating Models Fail in Dynamic Markets
A concise comparison of Predictive and Adaptive Operating Models, explaining why traditional structures fail in dynamic markets and how …
The Estimation Trap: How Tracking Accuracy Undermines Trust, Flow, and Value in Software Delivery
Tracking estimation accuracy in software delivery leads to mistrust, fear, and distorted behaviours. Focus on customer value, flow, and …
Getting Started with Objectives & Key Results
Learn how to successfully implement OKRs by aligning clear strategy, fostering transparency, empowering teams, focusing on outcomes, and …
OKR Guide - A Social Discipline for Shared Focus, Measurable Contribution, and Strategic Learning
A certification proves you’ve passed a test
Certifications show test-passing ability but don’t prove real-world product skills. Experience, judgement, and stakeholder influence matter …
Most companies still get Product Ownership wrong
Many organisations misunderstand Product Ownership, treating it as simple backlog management instead of a strategic, accountable role …