Reminder to myself

I jotted a few points that worked well for our team & in our context. So, it could work well for you too.
Product Vision Canvas::  
This is the most crucial homework a Product Manager could do for Hypotheses Validation. I will do this carefully before 1st line of code is written because it can save me a trunk-load  of cash burnt.
 
Hypotheses ::
Hypotheses validation does not get over with Product Vision Canvas.  Every User Story is a hypotheses. And that is why it should be built Slive-by-Slice.
 
Unknowns::
Accept the fact that there would always be unknown variables.  My job is to reduce unknowns and reduce impact due to unknowns.
 
Bite small, Chew well::
Make vertical slices of User-Stories. Never deliver a US completely at 1st shot. Deliver small slices (but often). If I screw-up, at least I will screw-up less and make quick course correction.
 
Shift Left::
Cultivate shift-left mindset across the team. That will safeguard me from unpleasant surprises (well, mostly). Shift-left is not waterfall.
 
Prioritization::
RoI would be my only criteria for prioritizing work (barring requirements related to statutory/legal/patent/security/etc).
This means while prioritizing, I should have a fairly good idea about the "value" & "Cost" of the work I will undertake. 
 
BugFixes is not value addition::
I don't reward myself when I fix a bug.  Maybe I stop frowning at myself when I fix it.
 
Telemetry Code::
Track the Behaviour of Customers. It helps in VoC. In fact, it provides a massive amount of feedback (just like VoC)  w/o asking a single Q to any Customer.
 
Infrastructure::
Defining coding style/Coding practice/Improving developer productivity/Improving security/Building automation/Infrastructure for CI/etc are more important than building features. (Repeat, *FAR MORE* important than building features.) Most talented/capable minds should handle this, rather than building features.  

Feedback::
Seeking market feedback on the latest release (and using it) is more important than shipping a new release (Repeat *FAR MORE* important than shipping a new release).  

A Small Change in a Spelling

In the Agile Industrial Complex, the biggest factory ships a 12-page guide which they call 'Rule book'. Customers buy this Rule book from one of their numerous retail resellers.

Many customers go back to their retail reseller and complain that these rules are neither helping them to ship value faster; nor it is improving their life in any way. In all such cases, the resellers have a ready answer…  “Those Rules are left intentionally incomplete. You should experiment and adapt.”
Sometimes poor customers gather their courage and ask…If something is incomplete, how it can be called a RULE? And when something is incomplete, why do you print "DEFINITIVE Guide" on the cover page?
But asking such questions is almost blasphemy in this new religion.

Going back, when they quietly changed ‘a’gile to ‘A’gile, very few noticed it.
But that was the time when the die was cast.
That was the time when an adjective was changed to a proper noun.
And then many brands were built around that proper noun. Many smart people (I deeply respect their business acumen) spotted a huge business potential in that small spelling change. The business model was to stamp people as MASTER and demand money for that.
There were (& are) millions of folks who paid for that stamp of MASTER with its literal meaning (i.e. someone having exceptional skill, knowledge, proficiency, and authority on a subject.) Many organizations also took the stamp of MASTER with the literal meaning and spent loads of money to get their people stamped as MASTER.

It seems these days there are very few Orgs who believe in the literal meaning of MASTER. Nevertheless, they continue to hire these MASTERs to update their JIRA.

When it comes to ‘a’gility (with small case 'a'), all a team needs to know and follow is….
- Collectively decide your End-Objective. 
- Bite small.
- Chew well.
- Ship small & ship often (because Speed matters).
 - Get f/b often (because Direction & Course Correction also matters).
- Take collective ownership of the level of accomplishment of your End-Objective.

This is a simple approach to be an 'a'gile team.

The problem with this simple approach is, it lacks the lofty aura.
It lacks pompous theories. It lacks complexity. Naturally, very few organizations show interest in it.
Complexity & inflated mumbo-jumbo sell better in the corporate world.

Prioritization

A never-ending and always engaging discussion thread among software product building teams is the Prioritization of Product Backlog.
To me, it is not (& should not be) a never-ending discussion topic, if we have clarity about one question.
That question is, WHY we are building this.

Discuss this with Sales folks & Developers and you may get something like...
-to win more customers,
-to make our customers happy,
-to expand our market share,
-to serve our global market with our self-sustaining,  carbon footprint-conscious, cutting-edge technology,
- Yada Yada Yada. 

Now add CFO & CEO to the discussion, and you may get one more answer...
-MMM ( Make More Money).    

Consider your answers and decide which answer matters most to you/your Organization before you decide HOW to prioritize.
Here is my super simple way to prioritize the backlog.  (YMMV)
- What gives better value, do that now. (Value to the Users/Market, and hence Value to the Product, and hence Value to our Org)
- What gives better value with less effort, do that right now.
- All other stuff should wait.  
It is that simple & straightforward.

Of course, to take that straightforward decision, I need to do some homework.
- I need to know where the VALUE is.
- For that, I need to be sufficiently outward-focused & understand the Market.
- I need to understand the difference between ‘A Particular User’ and 'Market'.
- I need to scout for the Right Market Needs.
- Finally, I must know that the 'Right Market Needs' are those, which are most sought after / painful for the market, AND most rewarding for our balance sheet.
In short, it all boils down to NIHITO, as Steve Blank said.

A few exceptions to the above super simple thumb rule for prioritization could be the work that involves…
-Work required to ensure ease of CI or
-Writing instrumentation code (Telemetry Data Gathering) or
-Setting up standards for the team or
-Defects fixing or
-Work required to acquire patents or
-Fulfilling statutory mandates or
-Derisking type of work or
-A strong demand from extreme-extreme-high-value existing customers. 

Work from all these categories does not (should not) pop up every day.
For routine Prioritization decisions, the above formula is super simple, and it works too very effectively.