Everything you do is wrong. You just don’t know it yet.
It’s Day2 of Blackbox Connect. 12 startups from 10 countries, and an amazing lineup of speakers and sessions over 2 weeks.
The team is live blogging here (w/ photos).
She led an awesome session on 10 principles of lean UX for startups. Here they are:
1. Everyone owns the product.
The lean product team needs 3 hats: UX, Developer, and Business. Each role has an obligation to the team, but they all have ownership of the product. The one line job description:
- UX role: _The empathizer in Chief._ Obligation to always know and share what the customer wants.
- Developer: Bring the technology lens to every decision. Share what is possible based on available technology.
- Business role: The scales of justice. Obligation to make hard decisions and tradeoffs when there are opposing views and imperfect information.
2. Put stuff on the walls.
Lean product teams need ‘information radios’. These are passive communication tools to keep everyone on the same page. Ideally physical spaces, covered in notes, stickers, columns. Distributed teams can be more creative (eg with products like Trello).
The concept here is to ‘work at the wall’. Have physical conversations and make decisions in front of this information.
The primary purpose: To get rid of the bullshit conversations, and focus talking on the stuff that matters.
3. Find flow: think/make/check.
This is a variation of the lean approach to build/measure/learn. The idea is roughly the same: do or create the smallest thing you need to learn what you need to learn.
In Janice’s words:
The experiment you are making is more important than writing the software. Resist the need to code everything… perfectly written code is a waste of time if the feature is irrelevant
4. Decide a work methodology. Make it repeatable and routine.
It doesn’t matter what the methodology is, but figure it out. How will decisions get made. What is the work process. Figure it out then make it repeatable. Then you can avoid wasting time reinventing the wheel each time.
However, you still need the ability to improvise. But when you do this, a framework makes it easier to get on the same page.
5. Focus on the most important customer problem (not features).
Solve customer problems. Sounds simple, but we all put our hands up with a list of features we wanted to build in our products. Her suggested process:
- Write down all the customer problems you know on cards
- Post them on the walls
- Rank them in importance (‘level of pain’)
Then focus only on the #1 problem. Ask: ‘what do we need to do to solve this problem’.
6. Define what success looks like when that problem is solved.
Be goal driven and outcome focused. Find the right metrics and drive towards achieving them.
7. Go broad in ideation.
When starting to solve the problem, come up with many more ideas than you need. An example: design 6 interfaces when you only need one.
Why? This seemed a crazy waste of time. She argued hard for the benefits of multiple versions:
- A single solution (or design) creates a lot of pressure to love the first version. Multiple versions removes this pressure
- They allow you to go beyond the obvious. The first version is usually the most obvious. The next and next requires more thought and creativity
- You can ‘exhaust creativity’ on the problem, making sure it’s all out there.
8. Be decisive, but hold your decisions lightly.
Then with many versions, you need to get really good at decision making. Decisively choose which features / ideas to go after. Acknowledge you will be wrong often, but that the lean process provides a safety net.
9. Recognise your hypotheses.
Know when you’re making a guess, and constantly look for ways to validate it.
10. Get used to doing research with users.
This one is maybe the most important.
Research with users is better than your guess, your investors, or wikipedia. Because no matter what else, if users don’t do the things you want them to do, you’re on the wrong track.
There’s a lot to adopt here, and we’re a long way from 10⁄10. It’s nice to know the benchmark.