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):

Who/When/Why?

  • Do I have enough information to decide this?
  • Is someone better placed to make this decision?
  • How quickly does this decision need to be made?
  • Does this decision need to be made at all?

User

  • What would be best for the user?
  • Do we know what would be best for the user?
  • Do we have time to work out what is best for the user?
  • Based on what I know about our users, what would be the best solution?

Technology

  • How long will each option take to implement?
  • What are the technical ramifications of this decision?
  • How easy is it to change the decision later?

Happy decision making!


Tara Bloom

Tara Bloom

A cynical & geeky cave dweller, Tara often ventures out to @madebymany to do a myriad of useful things. These include, but are not limited to: research, strategy, scrum mastering and propagation. Looking surprisingly like her avatar, she can often be found loitering here: @scandaloust

@scandalousT

Continue reading

Technology

Memories of WWDC

It's that time of year when the Apple developer community prepares for Apple's Worldwide Developer Conference (WWDC), an annual gathering in San Francisco...

Julian James   ·   2 June 2015

David Cameron is committing crimes against typography

Number 10 is now on Slideshare. That’s right, the slide hosting service loved by professionals and thought leaders around the world has been joined by the...

Isaac Pinnock   ·   29 May 2015

Technology

How we do CSS at Made by Many

This write-up aims to summarise our thinking about how to write CSS. It’s grown out of lots of conversations around best practices seen elsewhere, and ult...

Callum Jefferies   ·   29 May 2015