What is the day to day reality of working on a project? There are thousands of blog posts written about strategy, product thinking, design, methodology but ultimately when working on every day on a product, this isn’t the reality. The reality is emails, a lot of emails. And tickets. Decisions. And the challenges that documenting and communicating those decisions bring.
Projects require disparate disciplines of people to join together, working towards a shared goal. They also require tools to join together, notes, conversations, emails, Slack conversations. All these join to form the tapestry of what the product actually is. You look back at projects you’ve worked on and you don’t remember this. You remember the outcomes, the triumph (hopefully!) but you don’t remember the day that you spent wading through a bug report spreadsheet. Or the hours spent combing the backlog, re-prioritising and editing.
Products are made up of decisions, there’s the big ones — the strategy, the vision, the KPIs. There’s the medium ones — what features are must haves? What does this research mean? Do we need more time? More people? More budget? But then there’s the small ones, the ones no one ever sees being made or asks about. Is this interaction better than this? Is this bug fix good enough? Is this feature more important than that one? How long should we look at this? Is it “done” enough? Hundreds of these decisions fly past in a week, from all team members — technical implementations, design choices, product functionality decisions. One of these questions on its own isn’t enough to cause a product to fail, but without a clear vision to follow the answers to these questions become personal, subjective. People in the heat of the moment, under pressure, forget what every decision contributes to, they can fall back on what they would want, or reckons.
The other issue of course is that decisions don’t just spark and die, they have far reaching implications for the product. That decision you made on the fly when someone asked you a question between meetings? that decision could mean that months down the line a feature takes twice as long to implement. The decision you make based on what you’ve seen in another similar service? that decision could mean your users completely fail to understand how to use the feature.
Obviously some decisions need to be made fast and there’s nothing that can’t be changed later but consistently failing to check before you decide is a recipe for trouble.
Here are some questions which can help when making even the seemingly most mundane of decisions (or deciding WUT to do):