How do you react when you’re waiting for a page to load?
Tests done at Google in 2006 revealed that going from 10 to 30 results per page resulted in a 20% drop in traffic.
Why?
Because load time increased by half a second. Check it out.
It hasn’t always been this way…
In 1999, you would lose a third of your traffic if your website took more than 8 seconds to load. 7 years later, this shrunk to 4 seconds!
As the speed of technology increases, our patience decreases with it, and this metric is rapidly reducing.
To state the obvious, your user’s engagement is the most important factor to the success of your product, and never before have they been so in control, and so impatient.
What can we learn from this?
As humans, we crave novelty, speed and convenience and one of the greatest design considerations we need to account for is this acceleration of consumer demands and tastes.
For consumers, this has been a great thing. We’re continuously getting products and experiences that better serve our needs.
But for those who make the products it is making life distinctly uncomfortable!
The fight for our engagement can be seen when companies, who have mastered this speed, carry out experiments such as this:
This means that as consumers we are getting re-design after re-design shoved down our throats by companies that already have us hooked. Quite frankly, they have the resources to do so for the exact same reason.
Faster computers and better data means they can churn out insane variations of their product, very quickly. Get feedback, very quickly. Iterate, very quickly and get to a solution, very quickly.
However, this approach would take plenty of failed experiments to get to a solution and if you’re not a tech titan, you most likely don’t have the resources to carry out experiments like this.
So, how can we respond in a more resourceful way?
To answer that, let’s zoom out and take a look at the bigger picture to see what’s driving this…
We are drawn to live in cities such as London, New York and Berlin for their speed; living in fast cities makes us more innovative and productive; this generates better technology and new ideas; making our lives even faster.
Every time we go around this loop, we’re quicker than the time before.
There are many benefits that come with this trajectory which I wont go into now but as a sidenote, if you would like to know more— I would highly recommend this book which will tell you all about it in broad strokes.
Ok, back to business.
This is an exciting place to be but it comes with great uncertainty that affects all areas of our lives, from business, politics, relationships, media, music, and of course, technology.
Born to deal with this uncertainty were methodologies like Lean Startup and Agile.
It may not seem so long ago, but they were born at a time where the feedback loop was a tad slower than it is today. Put within the context of this rapid acceleration, and all of a sudden they feel out of date as we struggle to implement them.
Accepting the excitement of this uncertainty and wanting to be a part of the future means we must accept the challenge which is being the quickest from an engineering perspective, and delivering customer value at the same time.
In order to do this, we need to reflect on our product process and take a look at how this acceleration has affected it.
Lets zoom into the feedback loop we’re more familiar with:
It has become common knowledge now that because start-ups are risky and costly, its wise to validate early on; build only what you need and not more. Iterate as fast as you can, working in short cycles and then pausing at the end of each cycle to reflect on accomplishments, learnings, new insights, and next steps.
Making the learn part the most important part.
Does what we’ve learned indicate we should continue in the same direction? If so, let’s work another short cycle in the same direction.
However, if the feedback we’ve collected over the last cycle or sprint indicates flaws, we need to change course.
That is what it means to be truly agile.
There were 2 expectations at the core of this approach:
- What’s the most important thing we need to learn?
- What’s the least amount of work we need to do learn that?
Add the speed-bug to this, and what do we have:
Resulting in:
As a result, we’re in a feedback loop where we’re focusing on what to do next as opposed to what went right or wrong. This is where I believe the real-life feedback loop has affected our process. I feel that it is important we never disconnect the two.
So, what part of our process has it affected and how can we take the power back?
The work that gets visualised is the work that gets done — Jeff Gothelf
Whichever way you choose to visualise your process in your teams, your product development boards tend to look something like this:
Most companies practicing some form of Agile visualise their process with kanban-style boards using tools such as the Atlassian suite or Trello with a measurement of progress along the top and priority down the side.
I’d like you to take a look at your product development board and search for where the ‘learn’ part lives?
The most valuable part of our product process has slipped away in these tools, meaning we’re more likely going to react to the speed-bug rather than take control of it.
More from Jeff:
The delivery aspects of Agile get visualised, measured and executed. In this situation, Agile “wins” because the valuable activities of Lean startup and Design thinking rarely find their way into the same tools as the Agile activities. The result of this is that the learning work doesn’t get treated the same way as delivery work. It marginalises the effort and allows it to be cut in the event of a time crunch.
He goes on to say that to avoid this, ‘product discovery work must become a first-class citizen of the backlog’ and must be visualised along with delivery tasks.
But he didn’t really show us how…so we found our own way.
Thanks for nothing Jeff.
Just kidding :)
Over the past year, our team at Make Us Proud has been working on our approach to solving this problem which I’ll share in my next post.
