From Mind the Product 2019
Henrick starts, the most expensive gap you can have in a company is between the makers and users.
You can minimise the gap in 2 ways: time and in chain of people. Essentially, get feedback directly from users and quickly.
Lego do this regularly with groups of kids. Mojang do this with social media and a public bug board. I know Intercom is a good way to do this also.
Story Time: When the gap was large
In 2009, Lego began to release Lego Universe: it was like WoW, for kids, with Lego — an open do-what-you-want building playground.
They built it over 4 years (1000 man years) and then they shipped but “it wasn’t a huge success”. Players/users had not been involved in its development and found some things hard to do.
Funny side story: In one level they had a composer and a national orchestra. But it didn’t fit in the dvd capacity so was wasted.
Minecraft also allows people to build things from bricks. Minecraft’s first version was built in 6 days by 2 people back in 2009, and was released to a community forum. The community enjoyed it and suggested features and gave support.
After a year, they became a company. Then 5 years later they sold for 2.5 billion in 2014.
Even today Minecraft releases daily with the versioning strategy of 19W46B [WeekNumber-W-ReleaseNumber-Version]. Doing this early adopters get access to a potentially buggy but exciting new features publicising their use for the rest.
2 products that were almost identical — I will concede different distribution channels. Most people would have put money on Lego, but... users moulded the product. And that product won. [Minecraft is the biggest selling game ever.]
Release often to get user feedback quickly
This is also a compelling reason due to stress on your development team, Henrik suggests. If a train comes once a day, your spend all day being worried about getting it. If anything goes wrong you miss it, and disaster ensues.
If a train comes every minute, there is less stress, more chance to make sensical decisions and overall an easier journey.
The only issue is the expense of the ticket…
Slice the elephant
Nothing should be done all in one go — it goes against risk, learning and anything agile. A product should have many steps in the life cycle. Slice the elephant.
Autonomous means autonomous
Teams should have complete autonomy, have fun and be directly next to users. Having teams for understanding this feedback or doing QA for thnigs users wont like will mean the issues become permanent and continued appose to fixed earlier.
Daniel Eck (CEO Spotify) has said he would have killed the discover weekly idea but because the team had autonomy he had no knowledge of it. He simply put down the OKR and the team built discover weekly which addressed what he wanted.
Radical transparency needs to be present
For this to exist you need trust that no person feels like they are going to be fired, demeaned or other. That transparency allows indication of alignment. Like-wise business objectives need to be aligned and communicated:
If there are multiple teams they should be loosely coupled to others, but tightly aligned in direction. They should do demo or die sessions every so often, that anyone can come too, and have plans on the wall.
Henrik also champions curiosity over pride
Saying that pride will stop you learning, curiosity doesn’t. He frames himself as a marker, not a coder, and enjoys every opportunity to do so.
Go here to see the talk in full.
