How I used this book

When I started DSTOR to create a solution for blockchain content discovery , I knew I was addressing an issue that affected a large and diverse audience, including myself. Looking back at that stage, I would now say that I was moving in the right direction but my knowledge and context for the problem was too isolated to create a broad solution for such a diverse group. Luckily, the previous year when I was working at Amazon, where I lived ongoing discovery and customer-obsession every day, a friend had suggested I read the book “Continuous Discovery Habits”. With that book top-of-mind, and following the user-focused priorities I had become accustomed to, I was able to continue building in ‘the right direction.’

Work on DSTOR was an entirely iterative process, and although I can see a lot of missed opportunities in those initial stages for getting more diverse user feedback that I would now do differently, I believe that following such a user-focused path was able to keep the project moving toward a valuable north star.

My biggest takeaway

The first big point that author Teresa Torres writes about that deeply resonated with me was on the topic of Outcomes versus Outputs. DSTOR was and still is a small business start-up environment where all costs have to be very carefully watched and where outside contracted developers or community contributors frequently play a role. I recognized early on that it was a very different environment from teams I had worked on before and built products - where I would see the same faces in meetings and could more easily ensure we were on the same page in terms of deliverables and overall goals.

Within DSTOR, when I needed additional developers besides myself, I contracted out to a group in Brazil that had always demonstrated good work ethic and were reasonably communicative, although did not inherently understand the broader picture or desired outcome because they would frequently switch who would be involved. When working on a particular sprint, I would go over the deliverables, requirements and timeframes and check in routinely.

What I discovered in those early days of development was that the outputs would be as described, but the true outcome and impact on the user was left in the dust.

During the initial proof of concept beta phase there were 50 users actively testing the site, and with each piece of feedback received I would work to quickly implement their suggestions so that I could check back in and validate the changes.

In practice

In one example, a user expressed the need for more accessible documentation. I met with my team and we discussed and wrote up the changes to be made. When they finished, the documentation was improved but there was no intuitive way for a user to access it. I recognized right away that, I had emphasized to the team the outputs of the changes more than the desired outcome for the user. We were able to make an additional change to fix the issue in less than half-a-day , but I learned a valuable lesson during the process. From then on I made sure to always lead with the desired user outcome first, both verbally and on our change documents, to ensure any new joiners to the team would understand the true goal of the work.

I am happy to say that subsequent work correctly focused on the user experience. That experience has burned the phrase “outcome vs output” in my mind.