This October I attended the London JAM Conference 2015 - Sharing the Stories Behind Great Products. I'm primarily a developer, and so I went along hoping that some of the content would be relevant to my role, and the conference did not disappoint. These are my 5 key take-aways from the day.
Note While the conference had a great line up of speakers and all were inspiring, each of these lessons is based upon a point or points from a particular speaker. I've developed each of these ideas into my own for this article, but I've credited the original speaker under each.
1. Five Whys
(From Pip Jamieson, The Dots)
Five Rings is a famous book by kenjutsu practitioner Miyamoto Musashi on business strategy, later found to be applicable to martial arts and sword fighting. Five Whys is the second most famous concept to come from Japan about 5 things.
A technique used by the under-fives for millennia, it was formalised by Toyota founder Sakichi Toyoda (yes, the same one we stole all those other 'lean' ideas from) and is a technique to help get to the root cause of a problem. It's simple: ask "why?" 5 times when questioning a problem. The reason Five Whys is important enough to go on this list is that it's so simple, yet it's so easy to forget to do. There's a great example here from the guys at Buffer.
As a developer, try applying Five Whys when next tackling a bug: either apply to the problem you're trying to solve, or to your proposed solution. If applied to the problem, chances are you'll uncover the root issue rather than the special case your bug is. Applied to your proposed solution, you'll make sure you're actually solving the right problem. It can work in both directions, and it's like rubber-ducking on speed.
Put down that burger, I said 'Whys'!
2. Idea Incubator
(From Pip Jamieson, The Dots)
A good development team can be a great source of product ideas, but these ideas rarely see the light of day. This can be due to prejudice against ideas coming from Dev, or simply because they don't come up at the right time or get heard by the right people. It can be unproductive for a dev team to discuss ideas that aren't in the current sprint or in the backlog, but you don't want to discourage the principle. Idea Incubator is an outlet for this creativity: every two months, organise a formal internal pitch session where anyone can present their idea to Product. Keep it lightning-style: two or three minute pitches, and five minutes for feedback.
The benefits are legion:
- Everyone is given a chance to contribute to the product and so promotes inclusion.
- The sprint is not blown off course by discussing ideas that aren't yet relevant.
- It provides a natural filter for ideas: it seems like a great idea now with all this other work to do: will it still seem like a good idea in a few weeks?
- Another source of potentially great ideas!
3. Be A Customer
(From James Gill, GoSquared)
When developing or launching a new product, it's very clear that the on-boarding experience needs to be refined to perfection: firstly, to give the best possible first impression to your customers, and secondly, to make sure attrition is kept to a minimum. However, if you work on a well-established or long-running product, or a product people have no choice but to use, this part of your experience can easily be neglected. As a developer you may work in a sandbox that is far from the standard customer experience, or not us ethe same sign in process as them. Even worse: you might not even realise!
Once a month, sign up or log in to your app or site or service. How was it? Fast? Slow? Confusing? As a developer you may not be able to control all aspects of this process, but focus one the parts you can. Was the keyboard set to the right style? Did the spinners freeze? Look at the code: could it be more efficient? Run faster? DO things in paralell?
For those aspects your can't directly change - there could be a UX or business reason why the process is a certain way - it's still better to find and discuss them, so everyone understands what decisions have been made and why. Even in the worst case where you might not get a good explanation, you'll at least build up some empathy for your customers!
4. Use Processes, Don't Fight Them
(From Tim Davey, OneFineStay)
There are many ways to upset a developer, and enforcing process where it doesn't belong is right up there with telling them they're using the wrong text editor. When software is developed in a large team or organisation there are places where decisions must be made, or workflows adhered to, in order to keep the team running as a cohesive unit. They might seem arbitrary, but they are there to promote consistency, reduce complexity and therefore improve overall efficiency.
Use process in the areas where, as a team, you have a pre-agreed position on a decision that needs to be made regularly, or where there is a rule-of-thumb and it can usually be followed. By using process in these places, you reduce decision fatigue in your team and improve the quality of the decisions that they must make.
Culture is the way a collective of people can make individual decisions. By agreeing on and abiding by certain processes, you can create a team culture that encourages free-thinking but is fast, efficient - and most importantly safe - as the decisions are made within a consistent framework that you all fundamentally subscribe to.
5. Never Don't Not Use Data
(From Graham Paterson, Intuit)
The benefits of using data to assess your product are clear: it can show you why your product is succeeding or failing. What isn't so clear is the danger of not using data. If you don't use data, your product may be succeeding - or failing - and you will have no idea why.
Without data:
- you won't know why you have suceeded
- you won't know why you have failed
- you will miss illogical cases
This is why data-driven analytics aren't just a luxury: they are a necessity. Of course, data is never an excuse to not listen to customers too: the two need to go hand in hand to keeo your prodict on track.