Delivery Trap to Value Delivery…
Is your team good at delivering quickly while focusing on value for the user?
“We delivered five new features for our product in last few quarters, and yet we see increased negative ratings and low retention,” Said a confused Product Manager in a leadership call to assess critical performance issues of a Product.
“Our UX is not good; we have raised this during implementation too. We should have improved user experience and work on customer review comments to improve product performance,” said the Engineering leader.
The team fixed review comments one by one and some of the usability study feedback to see that their product performance has not changed even after so many efforts, changes, releases.
If this feels like a situation at your product team, too, then you are probably in a build-delivery trap even though you don’t realize it.
A Delivery Trap
The delivery trap is when the team is obsessed with delivering the solution without pausing to understand how it solves the problem, meets the product goal, vision, and broader organization objective.
Focus is on delivering products, services, fixes more quickly with pre-determined solutions, which came from some masterminds within the organization 😉.
To be clear faster deliveries may not necessarily be bad. Rapid releases are one of the main goals of DevOps, CI/CD to enable product teams to deliver their solutions more quickly to users. Delivery trap happens when our focus shifts from meeting business objectives, measuring outcome, achieving product vision to producing more and more releases, which ends up with no real value, even in some cases, impacts value negatively.
There could be multiple reasons for the delivery trap.
- Solution-focused mindset
Solution focus could be one of the critical reasons for the delivery. Teams believe they have solutions, without even figuring out what problem they are solving, for who they are solving it, does the intended user even want that problem to be solved.
They keep delivering solutions in the hope that this one will be the breakthrough feature for their product till they release another one 🙂
2. Output is rewarded over Outcome.
Teams could go into a delivery trap when they are measured and rewarded for their output. Their goal becomes how many things they are finishing and move on to the next things, without retrospecting from the last output.
3. There is no Product Strategy or Vision.
Lack of product vision or strategy results in a team delivering with whichever new ideas they could come with, without pausing to reflect on how this idea relates to our product vision and strategy.
Even if you have a vision or strategy, it becomes an artifact that no one remembers in some files.
4. Organizational culture hinders experimentation and learning
You know this may not work.
While developing, you feel either UX is bad, the feature itself needs the right problem statement, or needs more refinement after learning from the customer. However, the organization’s culture is top-down, focused on following roadmap and delivery commitments. So you end up delivering what is told to you rather than challenging the status quo and focusing on the right things to do.
5. You are following scrum 😉
You misunderstood the scrum guide on “output of every sprint is potentially shippable product increment.”
Scrum is religion for you, and as you believe you should be delivering something to the customer, you focus on creating more and more features.
I worked with a team where the directive from the top was that we need to release every sprint. Each team was given a goal that code changes should be in each release to add value to the product constantly. The effect of such a goal was that the team pulled trivial issues and defects to ensure they are working on them in the sprint to get something in the next release.
6. You measure vanity metrics.
You believe in continuous learning from your user and set up lots of telemetry with each feature. However, you forgot to think about what you want to learn from those telemetries, and you end up measuring vanity metrics such as product downloads, clicks, visits, etc.
These vanity metrics may let you feel that delivering more things is helping your users and business. However, without really learning, you end up adding more or more features without measuring, learning valuable insight from users.
The value delivery
The literal meaning of value is “consider (someone or something) to be important or beneficial; have a high opinion of”
value delivery is when your new product delivery results in added value to the user, helping you learn more about problems and solutions to meet business outcomes.
Value is the user’s perception, and your goal is to continue learning how effectively you are improving that perception. As the increased perceived value of the product will help you meet your business outcome much faster.
Value is the user’s perception
How to ensure value delivery
While frequent releases and delivery are great and good ways to make iterative changes, our goal should be to add iterative value to the product.
It needs a shift in our thinking that we will deliver something for the sake of it.
Some things which could help with value delivery
- Alignment on Opportunity
It is important to ensure that everyone has the same understanding of the opportunity. The opportunity could be anything such as a problem, which users need to solve, fulfilling some unfulfilled desires, Helping “Jobs to be done” in a better way, etc.
Externalize your opportunities and make visual charts to ensure everyone has a shared understanding.
2. Set sprint goals for opportunity
When you know what the opportunity is for you. Sprint goal should reflect how the delivery, release in the sprint is meeting that opportunity. If there is some work, which is not helping with the opportunity directly or indirectly, then it should instigate discussion about why we are doing that work?
3. Learning about the optimal solution should be part of the work
Even though you know what an opportunity or problem is, you are trying to solve it. The solution may need continuous exploration. It would help if you had enough slack in your sprints to ensure learning opportunities, exploring multiple ideas for the opportunity at hand.
4. Measure continuously
Measuring what you were expecting from particular delivery and what is perceived value of that delivery by the user is the most important part of continuous value delivery.
You should have identified metrics to measure, have a hypothesis that how your delivered solutions will impact those metrics, and how actually user reaction impacted those metrics.
Hypothesis-driven development will help you keep the opportunity in mind and externalize your reasoning for why particular delivery will meet the opportunity.
5. Assumptions
Most misleading assumptions are the ones you don’t even know you are making.
-Douglas Adams
Visualize your assumptions after your hypothesis. See how you can constantly test these quickly, and in case assumptions are proved to be wrong, scrap the mid-flight work instead of delivering for the sake of it.
6. Continuous Discovery
For value delivery, you must constantly be discovering opportunities with users. This discovery could be made using interviews, observation, walking in the user’s shoe to understand the opportunity. You had the right understanding of the opportunity, or there is now a more important opportunity to work.
This will help you ensure that your delivery is still relevant to the user and targeting the most important opportunities to increase perceived value by the user.
Wrap up
Value delivery is important than frequently delivering your product. As value is the perceived usefulness of your product, services by the user, it is important to focus on opportunity space; measuring perceived value by user for the delivered solution and continuous learning about the opportunity from a user perspective are key to ensure you are not running for delivery and stuck in the delivery trap. Instead, we should Deliver Less to Deliver More to our users in terms of perceived value by solving the right opportunity.
Simplicity — the art of maximizing the amount of work not done — is essential
- 10th Agile principle
