So it was time to start an initiative to:
- Actively and transparently value learning.
- Give a dedicated environment and the explicit permission to invest time for learning.
- Collaborate across teams and locations to get everybody closer.
- Spark innovative new product ideas or try new development approaches.
- Have fun together and celebrate us as a company!
The idea: Every first Friday of the month is now officially hackrday! The motto of our first one: "Build something fun connected to FlixBus". Follow me on my journey of our very first hackrday - when none of us really knew what was going to happen.
In the Morning
Looking forward to our first hackrday for days, some of my team members came up with a great idea what to build and I was eager to join. But when I came to the office that Friday, I learned that exactly those team members were not able to join the hackrday due to different reasons. That hit me quite unexpectedly and my "cannot wait for it" emotions suddenly turned into bad mood. And I started thinking about not joining hackrday as well to show support for my colleagues; but knowing I would regret not to experience the very first hackrday. Instead I convinced myself to at least listen to the other ideas being pitched and see if I like one of those.
As I entered the event location, another team I accompanied last year invited me to sit with them. And instantly improved my mood by providing some sweets - they know me too well! ;)). That team wanted to do what I had been looking forward to do with my own team: have a team project to work on, as a team. They kindly had me on their hackrday team as well. So I stayed; and did not regret it.
The Hacking Phase
When you consider the time required for introduction, pitches and demo sessions, having only one day did not leave much time for actual "hacking". So we had to use the time as efficiently as possible to have a maximum of valuable outcome at the end of the day.
- We got everybody on the team on board what the idea was about. We actually planned a minimum viable product which could serve as standalone solution or be integrated within some of our current products.
- We brainstormed what would be minimally required to implement for that product.
- After having a first common vision, we decided to split up and have sub-teams focus on different areas to develop that very first prototype.
- Then...
"Why do you assume that there is a problem for the solution you want to build?"Oh yeah. Well said. We were so keen on realizing our idea - we forgot about the basics. So we adapted the plan.
- The team's product owner and me set out to validate our hypothesis that the problem we thought of actually exists and that our tool would be able to solve it. We identified a set of questions which we assumed our potential users would answer positively; if so, our hypothesis would be validated.
- Have you been in the situation that you had to do X?
- How did you solve it?
- How happy have you been with your solution?
- What would you wish for?
- Do you know of any tool which would make things easier?
- Would you give us your email so we could inform you about a new solution?
- Any further remarks?
- We went through our office, asked several colleagues of several departments those questions - and quickly learned many of them had been in the defined situation but they did not have had a problem at all. They were really happy with their solutions!
- Next up we created some very simple UI sketches on paper, depicting a simple workflow through our envisaged product. Cut them apart. And again set out to get early usability feedback from our targeted users.
- We told them a scenario they should solve.
- We asked them to think out load.
- We gave them the paper landing page.
- And observing eagerly how they interacted with the paper product, trying not to give any hints, collecting their feedback.
- After doing this with only two persons where one heavily stumbled and the other even broke out, we had so much invaluable feedback already that we decided to stop and and re-design our product.
- So we draw more sketches, adapted things our users stumbled upon, added missing navigation which got them lost, and solved other unexpected issues.
- And while redrawing, without showing our next versions to any other users, we suddenly started to ask further questions ourselves. Is that feature really needed? If I enter this here, I should see it there... Hm, how to get back? So we instantly minimized our paper product even further.
- Back to another round of usability testing! And again, our users asked many valid questions and had a bunch of awesome feedback to improve our product.
- Then the other tester on the team came up with a stroke of a genius: While we were still focusing on paper, we forgot about all those tools for prototype testing and mockups which are out there! She used Marvel's mobile app to take photos of our paper prototype and linked them together to make it come alive and show the workflow. As time flew by we unfortunately could not have another iteration with users giving them this digital prototype. Would have loved to see their faces!
During the whole day we checked in with the team at least every half an hour, sharing our latest insights about the next best minimal solution. The team took them as input to build a very first backend prototype plus some UI parts. Hacking time quickly came to an end and we hurried to prepare a short presentation of our results so far - flying high on an adrenaline rush!
Lessons Learned
When each team demonstrated their prototypes, we found that many of them thought not only about fun stuff but about delivering business value with their ideas. Sharing our team's story how we identified our hypothesis as invalid caused laughter, but also taught some invaluable lessons for product development.
- Always test your hypothesis first. (We should have know better; we heard a talk about hypothesis-driven development only some weeks ago...)
- Assume your assumptions are wrong!
- Cut your product down to the absolut minimum. And then minimize it even further.
- Prototype quickly, test quickly, get fast feedback.
But we learned even more from this first hackrday.
- Personally I learned to validate my expectations as well. It's not about me or my team; the day was about learning and collaboration across the whole FlixTech organization. Glad I realized that in time.
- A low-effort presentation with handwritten slides supported the key messages of our 5min timeboxed demonstration really well. And it was worth shortly practicing it before doing it on stage.
- Due to the given time constraints, we felt the pressure to deliver in short time. We learned that we actually don't have as much pressure in our everyday work, even though it might feel like it at times. Despite the short time frame of the hackrday, we kept experimenting and learned so much valuable lessons by doing so. There are simply no excuses to not integrate experiments in our everyday work.
- We split our team to focus on different activities; but in the end it would have been worth to try mobbing for all tasks at hand. To not run in the wrong direction and waste time, but to avoid feedback cycles overall.
No comments:
Post a Comment