The hardest part of prioritising product

The most difficult part of building product with limited features is priortisation. The hardest part of prioritisation is staying consistent. After many years and many 'methods' I can say that sticking to one thing long enough to see results is most of the hard work. These days I am far less attached to methods and spend a lot more time trying to build consistency.

Why its tempting: Some days you feel like things are stuck. You're not shipping as fast as you once did. There's a lot to juggle and it feels a bit like chaos. If you just get the setup right, things might all be simple.

• Assuming that you're working on something novel you're going to spend a lot of time in the unknown. Problems worth solving don't have known solutions.
• If you're a maker it's hard not to have your maker hat on even when you're in management mode. You want to build systems that are optimal, ones that feel smooth and remove all the complexity.
• A clean slate is extremely tempting. You built from zero to your current setup so it can feel like a second shot at that will be easier.

It's easy to get stuck in a loop here. Restarting the first little chunk of a prioritisation system. Each time feels great in the beginning but it's easy to end up back where you started, this time with a slightly different configuration or process.

If you really want to ship good stuff, I'd recommend smaller tweaks at a lower frequency until you hit a point where its clear you need a major revision. Advice that is just as true for a complete codebase rebuild as it is for a rebuild of process.

Why it matters: Building product, either along or in a team, is a process of shipping the most good stuff as quickly as possible. Regardless of size, teams I have been a part of always have more they want to build than they can get out the door. The teams I've seen do well are the ones that manage to pick the right things to build more often.

• Choosing those things is tough. Even getting them onto a list can be a challenge but lets assume we have a list of ideas that aren't totally crazy.
• Ultimately we want to build all the ideas, but whether its a personal project, startup or large organisation it's nice to get signal that we're not wasting time.
• Just about every company that's reached a certain size will eventually publish a blog post on how they build product. Inevitably this will be some combo of team make up, prioritisation methods and (hopefully) feedback loops to know what got built is working.

In my early days as a developer and even as I started to manage teams, it was tempting to see some new method and be tempted to shift process. Every blog post paints a glossy picture of smooth running product teams.

Changing systems has two costs. First is an adjustment period, new systems take time to set up. Second is a false reset of expectations, we buy ourselves false time to let the new system get up to speed. The harder yet admittedly more boring option is to keep things going.

Advice to my former self: I am not here to say never change systems. Going from gut feel to some sort of ranking system will probably help. What I am advocating for is patience. Small tweaks to a long run process can add up far more significantly than big swings. It also helps in not causing blog-post-methodology fatigue throughout the rest of the team.

• When I am building things, on the tools building things, there's no better feeling than being in a groove. Maintaining process or making small tweaks helps maximise that feeling.
• It is fairly unlikely that anyone is going to write blog posts about their crappy systems. We don't hear about teams warming up to new methods, failed systems or down sides.

When your current system starts to really fail, you're going to know. Post it notes won't last long when your team grows. Customers will eventually bring in more requests than your system can handle. When you hit these points, revision is possible.

Changing systems because you feel like things aren't 'perfect' is not the way to win. Building things is hard and requires hard work, no methodology out there is going to change that.