Work /

Simplifying the Task Management Process with Kountable

The Story
If you haven’t already read about how we developed a global trade platform to scale with Kountable, start there. It provides contextual understanding for the following story.
Throughout a project’s lifecycle with Kountable, there are numerous transactional exchanges between a reseller and our trade generation/management teams. In order to provide the transparency our brand promises, we need constant communication and transactional documentation throughout the project. This is a story about how we uncovered a feature that would make this transaction simple, delightful, and eventually, automated.
The Team
The team consisted of a mobile engineer and myself to get the ball rolling and, over time, also included a back-end engineer, front-end engineer, project manager, and data scientists. 
This project was executed from January 2018 to January 2019.
My Contribution
For this project, I led a research quest that uncovered the need for a task management feature. Together with our mobile developer, I created a proof of concept feature which we proposed to our product team. After finding its way onto our roadmap, I strategized, documented, designed (for mobile and web), QAed, and iterated, iterated, iterated. Afterwards, I supported our data and project management teams in automating the feature.
The Outcome
This feature was a catalyst for a whole system of change in our product and, consequently, one of the things I’ve done that I’m most proud of at Kountable. As a result of the tasks feature implementation, projects were executed quicker and our entire product began to move toward an automated process, releasing our team members to do the work only their magical touch could make happen.
Let's Start at the Very Beginning
As a part of a larger initiative to turn four apps into one, I took quite literally “walk a mile in someone else's shoes” and became a trade generation specialists for a month. Interviews and insights are valuable but nothing can replace personal experience in order to empathetically solve problems your user encounters. I worked with our trade team in Rwanda to manage the procurement of a project from submission, through analysis, until it was understood enough to be evaluated and voted on by our Kountable approval committee.
I spoke regularly with our trade team mentor to gain contextual knowledge and understand next steps. This included what documentation was needed for regulatory reasons and how our team communicated that with resellers. I set up calls with my reseller to talk through documents and concerns regarding the project. Over time I began to learn the long process of project analysis and saw firsthand how often, embarrassingly, our product actually made the user’s job more difficult rather than aiding in their workload.

When I eventually steered my Kountable project successfully through the approval committee and received a resounding, “Yes! Let’s fund this project,” I handed it off to our trade managers to handle the execution of the project. 

I put together a participatory, step-by-step presentation of the project analysis process and presented it to our engineering team, allowing them to not only hear, but experience the pain points themselves. Again, my relaying of the experience would be helpful, but giving them as close to personal experience as I could was invaluable.
Our CEO joined in on the meeting and afterward said,
“This is the most important meeting we’ve ever had.”
We recorded the meeting and it became a required course instituted at new team member onboarding. 
Understanding the problem is only half the battle when it is within our power to do something about it. By gaining an empathetic understanding of the experience our users went through, I uncovered huge takeaways, some ripe for the picking to produce immediate improvements:
  1. Our trade team is incredible and works so hard! Totally automating the work they do would be impossible. However, we could slowly make portions of what they do more automated, freeing them up to do the important work only they can accomplish.
  2. There is a theory of consumer action called “Jobs to be Done”. It describes the mechanisms that cause a consumer to adopt an innovation. In the case of the Kountable application, we weren’t affording for many actions users needed to be successful, so our users were innovating to make those actions happen. For example, if the messaging portion of the Kountable app didn’t work, they’d email our trade team. In effect, when the Kountable app didn’t allow them to find success, they “fired” the app and innovated to find a solution that worked. This was the most devastating discovery: we were failing our users.
  3. Users fired the communication portion of our app. Communication took place on various platforms: email, phone, Skype, Koubel, Whatsapp.
  4. Users fired our mobile application. Our mobile experience was behind when it came to document uploading and this inhibited the reseller from getting the trade team the information they needed.
  5. Users fired our document management features. Our application was behind when it came to document previewing. This forced users to download documents multiple times which created security risks.
  6. Users fired our data model. Our internal application didn’t contain all regulatory data needed to accurately assess a project solely within the Kountable application.
In order to get hired back, our app needed to provide our trade team with the ability to interact with resellers in a way that was simple but robust, trackable but also afforded for an array of outlying use cases.

One key observation made while shadowing this project was that our trade team was communicating long, bullet-point lists of questions and document requests in messages to our resellers. All too often, bullet items were confused, conversations lost, or items missed entirely. If you’ve ever been a part of a texting conversation in which two topics are being discussed at the same time, you know how confusing that gets! In the case of conversations with these resellers, we were engaging in up to 10 of these conversations at once. Resellers had the answers to some of these questions while others needed follow up. It soon became clear how this onboarding process could take months to complete.
We knew we needed to segment these conversations and, if possible, simultaneously address other reasons for which we’d been fired. Our mobile developer and I hit the white board ideating various ways in which we could solve this problem. We took a divergent and convergent approach to thinking through this problem until we narrowed ourselves down to a few solid ideas.
Narrowing the Scope
The first of these solutions was a chat-bot experience which walked a user through the project management process step-by-step, giving a personable feeling to managing a project. The other, a task management app which gave individuals a list of items to complete before any given stage of a project was accomplished. We presented these solutions to our project manager and potential stakeholders (including the trade generation team) and were met with great support for the continued exploration of such a feature.
“This will be SO helpful”
—Trade Generation Team Member
“This unlocks so many possibilities.”
—Data Science Team Member
One of our stakeholders has worked with entrepreneurs for over 20 years in a coaching capacity. Leveraging her psychological understanding of entrepreneurs we agreed that more important than a hand-holding chat experience, was to engage this persona’s need to get things done fast and keep the ball moving. So, we collectively we decided to move forward with a task management system. 
We began reviewing all known requirements. The task management system needed to allow for various “types” of tasks (document uploading and clarification commenting at its most basic) and this data needed to be traceable over time.

I mapped the flow of this experience in which a trade team member creates the task, a reseller responds with some level of input, and then the trade team reviews the response, marking the task complete or asking for further clarification. As we created this flow, we uncovered outlying use cases which began to take definition.
The Beginning of Automation
In creating these flows, we uncovered a number of documents and basic project informational questions the trade team asked every reseller at the beginning of a project, regardless of any deviation from the atypical flow. Together with our trade generation and engineering teams we established a list of recurring tasks which could be auto-generated by an event trigger rather than by manual request. In so doing, we solved, to some degree, making a portion of task data automatically traceable. If we knew task A was created for the uploading of a contract document, then, once uploaded, we automatically directed the contract document to populate the correct locations across the trade team interface, thus solving to a degree the document management issues and saving valuable time for our trade team members.
Our mobile developer and I put together a proof of concept prototype to test with resellers in our Rwandan and Kenyan offices. When the day of testing was done, we iteratively solved issues discovered during the day’s sessions and before the next set of testers arrived the next day, we had a new iteration ready to test against. Over the course of three days, we tested this flow with over 20 users and created at least three iterations of the feature. By the fourth day, users showed significant improvements in their ability to use and understand tasks.

Before user testing, we thought all tasks should be in one easy-to-reach place, sub-categorized by project. This would allow users to quickly access the most important list to execute against in order to complete their project. However, in user testing, we realized that this confused users due to Kountable’s project naming convention differing from their own reference point to a given project. To fix this confusion, we nested all project information into one folder and added more robust notification settings to offer the same easy access to these important project management elements.
After polishing the final designs, I documented the agreed upon flow of information and presented it to our development team for implementation. Together with our PM we trained the trade generation team on how to best utilize this new feature for product adoption and when all teams were ready, we published the feature.

As soon as new projects were submitted, our trade generation team began adopting the task management feature to execute their projects and found a near immediate decrease in time required to complete the necessary actions formerly communicated via chat.
Take Two
Over time, we watched how our team utilized tasks with resellers and observed that while organizing tasks in project folders was the right decision, structurally having those tasks appear as collapsible and expandable cards was not. The card content had the potential to get extensively long and required the user to scroll in a manner that often left them contextually lost. So we went back to the drawing board for structural updates to tasks.
Automation to Scale
As a result of this project, our execution efficiency skyrocketed and, with much greater ease, team members were able to work on projects interchangeably as the project communication became much easier to scan. But perhaps the greatest measure of success for tasks was this project becoming the catalyst for a much larger initiative of automation from our data science team. When the fire ignited around the utilization of tasks, our data science led our product toward even greater automation of tasks and data mapping all the way through the happy path and all alternative routes. Together, we created a data schema to map documents and clarification tasks to the appropriate data points which initiated a much larger automation effort still underway today.
The Outcome
As a result of this feature discovery and implementation, users began hiring back the Kountable application.
  1. Users hired us back to communicate their project details
  2. Users hired our mobile application to manage these tasks
  3. Users hired our document management features and document previewing in-app
  4. Users contracted (not fully ready for hire) our data model, knowing more information was being captured in the correct place.
And on top of it all, we were able to begin the automation of repetitive tasks completed by the trade team catapulting our platform to scale. It felt good to have a job again!

Next Project