Equity in prioritisation

As your software grows, it becomes more and more important that engineers have a strong say in prioritisation.

Unfortunately this phase doesn’t last forever, and I think the main way to manage your path through later stages of development is through prioritisation equity.

The truth is, while many people in your organisation will be hired on account of their vision, insights and overall contribution to what you build into your product. Engineers are hired and sometimes designated, quite happily I should add, to the role of how you build the product.

So why is it important that the engineering department have a greater say in prioritisation as the company gets bigger? Let’s start with one of my favourite engineering quotes..

What Fred doesn’t mention here, is while users and designers of the software can interact with the castle, they can open doors, explore rooms, fire the canons and summon the jester. They can’t see the castle itself. That privilege is reserved only for the architects of the software; I can use Twitter, but I don’t really know what materials are used in its construction, or how different components are orchestrated, therefore I will never understand its full complexity and I will never visualise the castle that is Twitter.

…and as your castle grows it becomes increasingly more important to build things in the right order; you can’t build a drawbridge before you dig the moat.

There’s a simple way to create equity in prioritisation.

First, it’s important to differentiate product-led features from sales-led features. Sales-led features will often have deadlines tied to them and it’s important that your delivery teams strive to release them on time. Failure to do so will, at best, result in contractual penalties and upset/lose some customers and at worst, hurt your sales agents bottom line and damage the relationship between the commercial and delivery teams.

Now that you know the difference between product and sales led items, start grouping the product-led items. You can group them by number of features or by month/quarter/year, it doesn’t matter. Figure out what you would like to see at the end of each cycle and pay less attention to what feature you would like to see next.

By doing this, you give the delivery teams autonomy over the order in which they pick up features in this group. You’re still building the right stuff, but not necessarily in the order you first imagined. Trusting your delivery teams to pick the order that best suits your castle will result in less re-work, higher quality, greater velocity and generally happier and more motivated people.

Related posts:

I was always involved in marketing, PR, promotion and selling for as long as I can remember. As young as 7 years old, I was making Christmas and Easter decorations with other children in my school…

First formulated back in the Nineteenth Century, study into the Travelling Salesman Problem (TSP) was notably enhanced by the American mathematician Merrill M. Flood in the 1930s as he set out to…

Ford CTO Ken Washington, who used to be like my boss’s boss’s boss’s boss’s boss when I was at Ford, and seems like a great guy, has a post up about Digit, a humanoid robot that Ford is working on…