Meeting Our Users for the First Time

My team is developing an internal custom product for our company. This means, we only have expert users and we know exactly who they are. Well, you should think that at least. Truth is: We don't know them well enough. And although we're all working for the same company, we have never met.

The same applies the other way round: The users of our product don't know who we are, who is actually implementing this new feature or causing that issue they just found. Well, our user base grew a lot. And our development team evolved a lot as well during the last two years, with new team members joining, and others moving to different products or even leaving the company. And now we only have one person in the team left who had met our users once; a longtime ago.

To start growing closer with our users again, we agreed on the following two initiatives:

1. We want to have our power users and stakeholders again in our sprint reviews to get their instant feedback. Yes, we know it should always be that way - but truth be told, we had separate "team reviews" and "stakeholder reviews" during the last 1.5 years. Our product owner did a great job communicating user feedback to us, but something was missing. Having direct feedback right after each sprint is simply awesome for both sides.
2. We agreed to have pairs of developers go to Berlin and visit our users for two days, round robin style. So every developer has a chance to meet them, and they have a chance to meet each developer on the team.

Last week Thursday and Friday it was time for our very first visit! One of my teammates and I took the first round. We were excited to get to know the persons behind "the users", their everyday challenges and how our product might (or might not) support them to solve those.

Although our visit was quite exhausting considering the trip and all the pieces of new information, it was worth every minute. Our product owner did an awesome job preparing our stay and striving for maximum outcome for both us and our users.

• Big picture presentation. Our visit started off with two power users presenting what their job is about, what their work looks like throughout the year, the challenges they face, and which tools they currently use. It was a great roundhouse kick to show us the big picture, have first questions answered, and get us started in understanding what they actually need.
• Sitting with the users. Throughout the two days we used our multiple opportunities to sit next to our users while they were actually trying to solve a task at hand; some with our product, some additionally using other products, some not being able to use our product due to certain constraints. This learning time was invaluable for both of us. We directly saw which problems they faced. We saw which of our product features they used to solve it. We saw which of those features they knew about, which of them not at all, where they stumbled, what they liked, what they cried for.
• Power user meetup. Our product owner invites the power users every other week. This time we could join them and listen to the presentation of newly released features, to questions and answers regarding future implementations, the presentation of a user survey's results. Besides the big epics we're currently working on, the power users also have the chance to vote on their "user favorite" for our next sprint; a rather small but dear feature which would make their lives easier and which fits in between the stories for the big epics. This way they can not only help guide development by their feedback, but also directly influence prioritization in a small scope.
• Story mapping workshop. To close our two days' visit, our product owner hosted a story mapping workshop with a few users and us. I read the book "User Story Mapping" by Jeff Patton some time ago but never had the chance to attend one of those workshops, so I was really looking forward to it. And it was great! As proposed in the book, we first completed the simple exercise to map what you did this morning after waking up until you left your apartment. It really conveyed the method pretty well! Then we tried to map a real-life user scenario. And my group stumbled. What was easy during the exercise where we shared the same language, proved as difficult when it came to implicit domain knowledge. When the users told the story using a lot of domain language terms, I had my troubles to translate their meaning to my own world of thought. So I asked a lot of those "dummy" questions until we finally were able to map the required actions in a way that I understood them as well. This revealed a lot of implicit knowledge on both sides and helped us to a better understanding of what is actually needed to solve the scenario.

What about our lessons learned?

• The well planned schedule worked out really well; it was a lot of new information but not too much, enabling us to learn a lot.
• Now we know many of our users face-to-face - and they know who's behind that product they use every day. I know from experience that this will make future collaboration so much easier.
• We learned that we are actually working on the most important topics for those users - how great to hear! And that they loved the things we just released. Simply awesome!
• The two days in the life of our users provided great insight in how we could develop our product further to support their challenges even better.
• We shared a lot of implicit knowledge; not only the users with us, but also the other way round. For instance that our team does not consist of the 15 developers they thought of, and what technical debt is all about.

In the end, we shortened the feedback cycles with our users. Both my teammate and I are pretty curious what our other colleagues will tell when they return from their visit. And we're already looking forward to our next turn! :)