What motivates my product process

And the case for marginalia

I changed office locations last month. Following the move, I pulled a book off the shelf that I hadn’t noticed in a while and was delighted to find it filled with notes, underlines and folder page corners.

A glimpse into the obvious excitement of my younger self. This book was the first time I’d seen that there was a method behind the madness of product development.

I was transported back to the Autumn of 2009. I was an engineer at Yahoo! Sports and we were embarking on an ambitious global project for the upcoming FIFA World Cup in South Africa. I remember the team being ushered into a room for a whole day kickoff with the product and design folks. After intros, the following line was delivered:

If you find yourself thinking “What if…?”, keep it to yourself, we don’t have time!

It floored me. We were not a passive engineering team. We cared deeply about what we built and our audience. So to be excluded from the process and spend a day being told what to build, with no wiggle room because of an aggressive timeline, was disheartening. This wasn’t a kickoff, it was a dictation of 9 months of uninspiring work.

I know from experience that it’s fine to focus meetings in this way, but to provide no outlet for the questions and poking so essential to entering into a project was ugly. It retrospect, it was likely a symptom of the following problems:

1. The discovery and product phases were skipped or rushed. This left a gap where the product vision should have been, necessary to layout a clear path and get the team aligned
2. The entire project was approached defensively rooted in a patchwork of opinions of what an event website section should look and behave like. There was no vision or thought given to how we could approach it in a more deliberate way
3. Senior engineering had a disproportionately large hand in guiding the direction of the project — true of many of Yahoo!’s failures. Much of the complexity of the project was self inflicted by trying to be a good corporate architect adopting future internal technologies and little known systems in the hopes of skating to where the puck was going. That left little room for product and design. And it turns out we were chasing the wrong puck from the get go, and the product suffered as a result

Truthfully, this is far removed hindsight, I have no idea what was actually going on — but I do know that there was significant room for improvement based on how I felt as a participant and contributor to the project. It’s also worth noting that I respect and enjoyed working with the product and design teams. Organizationally, the engineering led hack culture didn’t make it easy for them to make space or succeed.

Turning bad experiences into motivation

Much of the marginalia in the book I re-found was from this time. It reminds me how great it felt to discover there was a process and a discipline dedicated to delivering predictable product results. It helped ground the discomfort I felt instinctively. I was a backend engineer with an academic Computer Science background, yet it’s clear in retrospect that I was already itching to get upstream, out of code and into product.

Eight years later and I find myself leading product discovery for a similarly ambitious, multifaceted and business driven project. I think of experiences like the 2010 World Cup often and they fuel my desire to lead the product process right.

It’s easy to skip phases, leave folks behind and spend time being busy; a victim of impossible timelines. It’s really easy to do that if the organization or client isn’t open to the steps of a formal product development process and wants to rush to a deliverable.

It’s hard to be diligent, to rally the team around a vision and to make good use of the available time. But I owe it to my younger self to push for whats right. And to ask “What if…?”.