You lead a product engineering team. How do you decide what work to do next?
▶️ Whatever the customer asks for or may want.
▶️ What the boss wants
▶️ Prioritise the Highest Paid Person’s Opinion (HiPPO)
▶️ Choose the feature based on an estimate of the potential revenue generated?
▶️ Work required to meet legal and regulation requirements
▶️ Whatever ‘feels right’. Just because.
▶️ Follow your gut. Your instinct.
▶️ Tech Debt.
▶️ The ‘ilities’. The non-functional requirements. Work required to meet performance, scalability, security, resilience, availability etc.
▶️ The low hanging fruit.
▶️ The bugs.
▶️ The feature which will get you the experience you want to show off on your CV.
▶️ The largest impact on your key metrics.
▶️ Whatever your OKRs dictate.
▶️ Whatever feature has been sized and fits neatly into the remaining sprint.
▶️ Weighted Shortest Job First (WSJF)
▶️ Copy the competitors. Competitor Analysis.
▶️ A feature that appeared in a dream.
▶️ Whatever the sprint team decides is the next priority.
▶️ The loudest voice in the room.
▶️ The census ‘priority feature’ voted by the committee.
▶️ The feature pushed by the most passionate voice in the room. ‘I PERSONALLY believe …..’
▶️ Who cares about business priorities? That’s the Product Owners problem. I just code.
▶️ The most senior voice in the room.
▶️ The next item on the list.
▶️ The feature that you believe will most move the company towards the vision and aligned with the company goals.
▶️ Prioritise potential features based on a combination of estimated value and cost of development.
▶️ Taking bets on features and learning from users how they performed. Data driven decisions.
▶️ Bike shedding. Let’s prioritise what’s easiest.
How about you?
Will be interesting to hear how other software development managers handle prioritisation.
How do you do it?
Jamie Good 