Creating a tool that users value is an important goal for each product team. Truly addressing our users’ needs, simplifying their tasks, or making them delighted, keeps us motivated and pushes us forward. But it is not easy to achieve.
Since May 2015 I’ve been part of the Akvo Flow product team. Our main focus is to create a powerful data capturing tool. For me this means understanding where our partners experience difficulties, identifying what changes we want to bring and constantly seeking improvements. I ask ‘Why?’ a lot. Satisfying this curiosity is one of the many reasons why I love my job.
Unanswered questions
In my first year at Akvo, I was very excited about each new change we made. They all seemed so useful when we were defining them and my excitement grew seeing the ideas come to life. But often I had these ‘Why?’ questions lingering in my mind that remained unanswered. I was not sure why we were working on that particular change at that moment in time, or why our users would really care about it. And when it came to bringing these solutions to our users, more ‘Why?’ questions started piling up, such as why, after writing all these user stories, were we still not sure what change we aimed to create? Or why others in the Flow team seemed not to understand how the change should work, despite the long and detailed documents we prepared.
Don’t get me wrong, I am not trying to say that what we were building was not valuable. Flow is improved with each release and we have seen a rapid growth in usage spreading out to different sectors and regions. What I mean is, that I personally felt the need to know more and do things differently in order to be able to bring the improvements I was striving for.
Above: Reading User Story Mapping by Jeff Patton. Photo by Jana Gombitova.
Top: An illustration from the book User Story Mapping by Jeff Patton.
The missing puzzle pieces
When searching for alternative ways of developing products I stumbled upon the book User Story Mapping by Jeff Patton. I was hooked. User story mapping is based on fully understanding the problem you want to address and talking about users using your solution. With each new chapter I felt that user story mapping can help me find answers to my ‘Why?’ questions.
Until this point, when developing Flow, our process consisted mostly of creating long documents. We wrote lengthy outlines of user stories and long descriptions of how the solution should behave – in other words, we already had a solution in mind. These documents were then shared with design and development teams, at which point it became clear that we did not really have a clear view of what the problem was we were aiming to solve.
As Jeff Patton points out, you need to start by learning about and narrowing down the problem. Once you are clear in your working group on what issue you are aiming to fix, for whom and why, you should talk about the actions your user takes, if she has your solution. In other words, how will the user interact with your solution to resolve her problem? You map out her workflow and define it in more detail. Then slice it down to the most minimal solution, that still allows her to complete her full workflow, but is small enough for you to build and test quickly.
Right from the initial discussions, you bring together business, design and technical team members to not only generate shared understanding across the teams, but also to ensure that your solution is valuable, usable and feasible.
I decided to give it a try. Following the principles and steps outlined in the book, I experimented on a few small cases and my enthusiasm grew with each exercise. Therefore during our Dev Team Week in Riga in September 2016, I shared my experiences with this alternative approach with the team to hear what they thought. After the workshop I was humbled. Not only did the team feel this approach can help us feel more empowered, but everyone was eager to start trying it out.
Below: Jana Gombitova presenting the concept of user story mapping to colleagues at the Akvo dev team meeting in Riga in September 2016. Photo by Marten Schoonman.
Rolling out user story mapping within Akvo
Since Riga, I have held numerous user story mapping sessions in Akvo with different product teams in order for all of us to become more familiar with the process. We’ve covered topics like understanding the use of Flow’s online workspace; different upcoming Lumen features; defining the second iteration of RSR’s results framework; thinking of what data science as a service can be in Akvo; or starting a new project around tracking the use of our tools; and many more. We also held a few user story mapping learning sessions, where we covered the core principles in more detail and shared what we have learnt so far in the trial runs. User story mapping is finding its way into the different product teams.
Above: Understanding the use of Flow’s online workspace with our partner, ICCO.
Below: Looking at how we currently track the use of our tools. Photos by Jana Gombitova.
When looking back at all that I have done so far, from the moment I started reading the book until today, I realise how much I have learnt. I am grateful for having the space to try out new ways of working and humbled by having colleagues willing to try them out with me. I believe that the principles and practices of user story mapping will help us create the solutions we strive for. I feel that now I have better answers to my ‘Why?’ questions.
There is still so much more to learn. I am only at the beginning. In the coming months we will continue using user story mapping and its principles to guide how we create our solutions, and I will also continue improving myself. My next milestone, that I am really looking forward to, is taking part in a course with Jeff Patton himself on product management. So stay tuned, I feel there will be a lot to share…
Jana Gombitova is Akvo Flow product manager, based in Amsterdam. You can follow her on Twitter @janagombitova.