Before going to the LeanUxFest conference, I did not think LeanUx was going to trigger such a shift in my mind. I was struggling for month to resolve internal disagreements about the design process in an agile environment.
The main concern is that agile is brainless, it solely focuses on collaboration and delivering feature. It doesn’t always take the time to ask himself the question: “Are we making the right things?”
Amazon can ship in 11,6 sec but has this sensing layer that allows him to roll-back if the kpi’s are going down. Fast delivery is great because it allows you to get quick feedback and react on it.
But why do you need that?
Yesterday assumption dont work with todays realities
Between Roadmaps, features, useless meetings, funding rounds, strategy shifts, … how do you start learning from your customers and measure success? Here are my notes and thoughts compiled for you.
Maximizing creativity and learnings from the product
Nowadays, every company that as a bit of scale is a software company. Even the New York Times switched to be a software company that delivers high quality journalism content instead of journalistic company with an online presence. link
And every software company that need to scale need to think about creating a global learning culture instead of creating individual silos. In return it will help the team to make evidence based making decisions and improve the global quality of the product.
Many time we assume the projects managers or cto’s know best but in reality we never know how it’s going to end up. The idea is to quicker validate our assumptions so that it can drive our future decisions. The more swings you take at a problem, the better.
Focus on the problems and not the features
From Jeff Gothelf talk the 5 steps to achieve that should be:
The Anatomy of the team
Thinks to avoid:
- creating silos (it limits the creativity of the team and prevents collective decisions and learnings)
- working with service providers (because they don’t own the product, they don’t care as much)
- having no view on the “whole”
- having no collaboration
- tasking people based on their availability
All that leads to less team cohesion, frustration, product quality and less productivity.
- small team (6-8 people)
- co-location (if not possible, be awake at the same time)
- dedicated (everybody work on the same project)
- self sufficient (you need the skills but not the roles!!)
How do we task the team
Thinks to avoid:
- Roadmaps (fixed time and fixed scope often makes the deadline move, reduces the scope or makes you work crazy hours)
- Annual budget process (as we had any idea of what’s gonna happen)
- create documents with active initiatives, revisit priorities along the way
- Task the team to achieve business outcome
- get granular (the agile way)
- give the team a problem to solve not a solution to implement
- let the team own the solution (stategic and tactical kpis)
- have a incremental funding company structure (small chunks of reliable funding)
If the measure of success is features, the product becomes bloated Roadmap should be a list of questions not features! Features on their own are not a measure of success
How should we work
Thinks to avoid:
- having no cross functional collaboration (you should have)
- fixation on job titles (that limits the creativity of the team)
- fear of failure (then people tend to do just enough to not get fired)
- arbitrary deadlines
- no culture of ownership (cover your ass)
Change how the team works:
- take smaller risks
- usually agile doesn’t have a brain -> implement a learning brain to agile
- works as designed is not enough (you have to focus on QA and change it if people can’t use it)
- clear definition of success
- promote competencies over roles
- self organizing team (let the team figure out how they work best together)
Why should you invest for this culture of innovation
- its gonna make your customers happy
- reducing waste by building successful product
- increasing employee’s morale
You must transform from a culture of delivery to a culture of learning
They are multiple tools at our disposal to collaboratively iterate over design considerations:
Empathy Mapping helps us consider how other people are thinking and feeling. Its a quick way to enters into the head of our users and consider the problems they have while using our products. It’s stimulates teams to find innovative solutions while building knowledge about our clients. (source)
This sketch-boarding technique called the 6-8-5 method asked team members to produce 6-8 sketches in 5 minutes. By limiting the time frame, this force us to focus on the essential. (source)
One of the most important aspect about leanUx is to create ownership
Facts checking map (post-it board)
In order to evaluate and prioritize our assumptions and facts while exploring a problem, it is useful to draw a big line on a board and organize the post-it from ‘not true’ to ‘true’ (make sure true statements have evidence to support them).
Not sure <—————————————–> True (with evidence)
Do less More often to do More
Mapping Problem to personnas
Make a collective brainstorm and define :
- What is our goal
- What is the problem hypothesis
- What is it we want to learn
- What are our assumption?
- Which assumptions can, once proven false, invalidate all others?
- What is the minimum we can build to learn?
- What is the measure of success?
- Get out of the building and talk to people.
- build mvp without full fledge backend, do experiments and measure results.
- keep track of feature release date to match with analytics insights / pikes > Minimize efforts and maximize learning