Design thinking and my journey from software developer to product owner

Kristen Seversky EagleDream’s 2018 TECHTalks event at RIT
The author's “How to Quantify the Human Experience” talk at EagleDream’s 2018 TECHTalks event at RIT (Credit: Eagledream Technologies)

I call myself a product-owning, design-thinking, code-writing, people person. To get to this point in my career, I spent nearly a decade as a full-time developer: learning various coding languages, leveling up, and assimilating to the tech industry. All of this followed a decade of tinkering with computers, mystified by the concept of the internet. I gravitated toward the ability to connect with people from all over the world, and I was lucky to dive into this affinity, get educated, and make a career out of building software.

My social butterfly tendencies were at odds with the stereotype of the introverted developer. Seeing fewer women in these environments put another dent in my sense of belonging. I wanted to challenge the notion that being antisocial is acceptable in an industry that creates solutions for humans. Software needs great communicators, yet the industry tends to lack decision makers with strong people skills. I vacillated between the idea of calling out this deficit and staying focused on delivering quality code. Fortunately, a shift was coming that would make my next move rather obvious.

I could no longer deliver code without an adequate “why” or at least the research to back the direction.

Enter design thinking! I was working as a senior developer at a small, tech-driven, B Corp that hired Cooper Professional Education to conduct a three-day training. I had yet to explore design thinking, but design and user experience were top of mind through my coding career. Design thinking brought the necessity of human research to life. Within the short training week, I felt my career requirements shift. I knew I could no longer deliver code without an adequate “why” or at least the research to back the direction.

After the training, I focused on networking with people who put the solutions together. I figured that if I couldn’t get immediate access to end users, I’d at least focus on improving processes that internally serve us. This was also about the same time I learned about Conway’s Law. In 1967, computer scientist and programmer Melvin Conway coined the adage, “Organizations that design systems are constrained to produce designs that are copies of the communication structures of these organizations.” Basically, systems and solutions that we generate will most likely reflect the systems and dynamics that built them.

I used Conway’s Law as a cautionary tale for ongoing solutioning without ample communication or at least a pulse on the end users. Too often, I found myself at the end of the project river with code and business requirements but no image of the people for whom the solution would be built. This blatant disconnect dehumanizes the whole process and inevitably moves us further away from delivering solutions that address human problems.

Design thinking offered a process for hypothesis testing, user interviews, synthesis activities, and more — all of which brought us closer to our clients. Even better, the framework could be applied both internally and externally. I was focusing not only on our clients, but also the various leaders in our department, to ensure that employees were working in processes that best served their needs. We were on our way; so much so that I left my coding role to become a design thinking strategist.

Nobody could believe that I was leaving a decade of coding behind, but I was so drawn to the people and communication issues in tech that the binary, semi-predictable nature of programming no longer enticed me. I had made a deliberate effort throughout my career to straddle the line between the disciplines and maintain a well-rounded position on the software development spectrum. Now, I was shifting toward the discovery phase to learn what it is we should be solving and why. I also expected to inform the coding portions, as I still had a grip of the code and possibilities.

In my new role I worked on the adoption of the design thinking model across the company, which included partnering with leadership, influencing agile processes, and rotating participants from all departments into our workshops. My goal was to keep shifting the mindsets at all levels to unify the purpose behind our products and efforts. While not everyone embraced the framework, these conversations helped people realize how far removed many of our decisions were from our users. Other noteworthy adjustments:

  • Scrum masters and team leads emphasized the need for both a “who” and a “why” when writing stories or establishing sprint goals.
  • Product owners recognized the benefit of different strategies and approaches throughout the development process.
  • Sales representatives listened for stories to help inform the paths towards solutions instead of forcing a product into the picture for the sake of a sale.
  • Bias and agendas were spotted during the synthesis process (conducted in groups), which prevented one voice from declaring the takeaways. We were closer to objective data than ever before.
  • Developers questioned their approaches now that they were more aware of the use cases and goals.
  • Marketing was able to leverage the synthesis results and see new opportunities that scratched below the superficial customer needs.

I was conducting interviews and capturing stories from a wide variety of our customers so I could analyze the results and spot patterns moving forward. The key was listening to what people were doing in their roles instead of asking what they want, as people aren’t always great at building solutions for themselves. This strategy forced me to become more patient and thoughtful about client interactions, paying attention to the subtle details. I enjoyed this new position and the speaking opportunities that came with it.

Anyone taking on this effort will also have to face the reality of the culture shift that comes along with it.

After half a year, the common issue with frameworks in the workplace started to bubble up: people were focused on process instead of mindsets and questioned the return on investment. How effective you find the design thinking framework heavily depends on how much time and money you’re willing to invest. Results vary greatly.

Some companies have the resources available to run extensive interviews and workshops with clients, resulting in substantial, qualitative data. Others might need to find an “express lane” of sorts in order to improve data research wherever possible. This might seem inadequate, but it’s a step in the right direction. Anyone taking on this effort will also have to face the reality of the culture shift that comes along with it. Certain people will resist any change to their daily routines. After a year, I saw that my priorities were not aligned with the company’s goals, and it was time for another role change. I wanted to stay close to the heart of human-centered problems, so I explored options that would merge my interests. I took a leap of faith toward technical product ownership.

I’ve been a product owner now for a year and a half, and I draw on my design thinking background whenever possible. No matter the project, I try to chisel out my own personas or target demographic (internally and externally) at the core of my decisions. I gravitate towards our support teams, as they manage both end-user interactions and their own jobs of navigating clients through our products. This perfect melting pot of user data offers plenty of design thinking opportunities, and I intend to pull new ideas from the mix through interviews and workshops.

Design thinking isn’t a set of laws; it’s a shift in focus that re-centers humans at the core of our work.

I appreciate the guiding light of design thinking, as large portions of a long-standing, business-critical, software platform can easily intimidate anyone looking to improve processes. I’m excited to dive into these spaces, soak up information, identify our “who” and “why,” and then workshop and prioritize ideas that can positively impact the product experience. Iterate, iterate, iterate. My previous role taught me when to double down or back off from applying these new approaches. I’ve also received additional training in the form of compact workshops, which can appeal to departments that aren’t quite ready to devote months to the effort.

Design thinking isn’t a set of laws; it’s a shift in focus that re-centers humans at the core of our work. We’re a bunch of humans building solutions that humans will use. Maintaining exposure to their realities is our only means of actually solving problems instead of indirectly creating new ones. It’s an ethical agenda.

Kristen Seversky
Kristen Seversky

Kristen Seversky is a product-owning, design-thinking, code-writing, people person striving to make tech more meaningful and inclusive.

Learn more

Subscribe to our mailing list and stay up to date on our latest thought leadership and learning opportunities.

Connect with us

Want to know how we can help your company drive real business progress?

Let’s talk

Stay up to date on our latest thought leadership and learning opportunities