Update: this story was featured in Cooper Professional Education’s journal site on 2/4/2020

OK! I’ve finally gotten myself to focus on this effort to talk about my journey from software developer to design thinking strategist to a product owner. Let’s dive right in.

What this is about:

• Using my story to highlight opportunities for change. I get weird when I become too familiar with things or comfortable in the day-to-day routines. A cathartic activity for myself is ruffling my own feathers and, sometimes, I try to poke others along as well. Maybe you’ll see yourself in my story or perhaps consider an option you told yourself to ignore. Never know!
• Starting a conversation. I don’t know if this post will do anything other than suck up your time. I hope it does a bit more, but ::shrug:: I’m just tossing more perspective into the ether for anyone to consider. Y’know how I like to keep an open book 🙂
• Answering your questions. I recently put out a probing tweet to see if anyone had questions or wanted to be a part of this role-shifting discussion and I got a lot of responses so thank you for asking them! I am going to try to hit them all, but while maintaining some flow as I see fit.

What this is not about:

• Where I work. I don’t want this to be interpreted as a byproduct of the various companies I’ve served, but more so a summary of my personal experience in each role. You can figure all of this out if you really care, but the “where” I worked is less important to me than “how” I worked.
• Being an expert in these roles. I pride myself on having lots of interests and shape-shifting my way through my career so I won’t sit here on a high horse like I have all the answers. I won’t nor do I want to hit a point in my career where I even *think* I have all of the answers. I’m just here to reflect upon these jumps and share what they’ve added up to thus far.
• A deep dive into each role. For the sake of brevity and everyone’s sanity, I want to keep this somewhat focused on my path and the questions I was asked. Feel free to use the comment section or more tweets to keep asking more!

Real quick: I don’t want to hear the noise about this being “soooo loooong.” I’m trying to be thorough for those that are seriously considering this path while also cutting to the chase for those that had one, specific question. Hope this works! ONWARD.

---

So what brought me here? I’ll try to keep this short. Note: I suck at keeping things short.

I’ve been fixated on computers from the moment I got access (7–8 years old) to the level that my mom would put “15 minutes online” as surprises in Easter eggs. Better than candy, folks. I firmly believed the internet could lead to world peace, too. So many communities and people at my fingertips and I wanted to meet them all. I admittedly still believe that our future, global understanding is there, but we have lots of work to do while we’re distracted by memes, cats, and misinformation.

Despite all my years of being on computers, my coding career wasn’t obvious to me at first. I owe it to my high school math teacher for nudging me to take our token programming class (Visual Basic) and only then did I watch my logic-loving side collide with my creative side. I was sold. I found my thing. PEOPLE. THANK YOUR TEACHERS. HOLY HELL DID SHE CHANGE MY LIFE.

One thing to add here if you didn’t know: I’m extremely outgoing, extroverted, talkative, and a big fan of people. I was dubbed a social butterfly early in my life and my energy can sometimes earn me a tornado-like impression. I’m highlighting this because I spent a large chunk of my career handling the “you’re a developer?!” moments, as stereotypes solidified the “developers aren’t social and usually avoid people” nonsense. I also trained myself to focus and quiet down so I could blend in a bit better with expectations. Now, I won’t sit here and say it was out of desperation or anything dire, but I hadn’t yet recognized that my social skills were a huge strength and missing link in these realms. I finally figured out how to turn the tables in my favor and spared any imposter syndrome moments. I knew I loved computers, the internet, and that I could connect with the most people through them. Nothing would get in my way of seeing that through. I wish that mindset upon anyone entering or feeling lost in this realm. Especially for those that have to deal with greater levels of gatekeeping and societal nonsense than I ever did. Every little bit helps.

---

SOFTWARE DEVELOPMENT

First up, my software development years. After my ~6 years and two degrees from RIT (Go Tigers!), I found myself knee-deep in JavaScript, PHP, and WordPress jobs. I was maintaining in-house servers while building solutions from database to UI to customer service. I was the true Full Stack Developer long before we trashed the title. Snark aside, having to take support calls for big projects that I built on my own was a fantastic learning experience. I really wish more developers were closer to support, as seeing the impact of your code is pivotal to understanding the problems you’re attempting to solve. I also think this was an early catalyst to my eventual job transitions because I never wanted to be too far from the end users.

Five years in, I shifted to new languages — Ruby on Rails, C#, embedded fun with Android/Java, custom CMS, etc. — and crossed into the wonderful world of JavaScript framework chaos. I was also routinely freelancing by this point and sharpening new skills on a variety of projects and languages. I really liked knowing I could solve problems through code and that I was good at it. I rarely get in the zone for anything quite like when I’m coding so I was often super relaxed as a bonus. NOTE: this is not an endorsement for “hey, do more work outside of work!” attitudes; freelancing is simply a way for me to satiate myself when jobs cannot (and might never) cover all my bases.

This balanced trifecta of full-time job, freelance work, and nonprofit duties lasted a good four years before my “shake it up” senses began to tingle. I was feeling as though I was too far down the decisions river without the big picture. I’d disengage at work if I had to code without a clear “why” or the “who” in the effort. Worse, I’d hold up meetings when others didn’t need the big picture. ::cringe:: Any attempt to chat with other developers about the big picture often resulted in hearing, “Meh. I just do what I’m asked and go home.” This recurring answer created another concern that was deeply rooted in my values and ethics, as I believe developers have an enormous responsibility in what goes out the door. I recognized I could no longer just do as I’m told without question. I needed to get closer to the decision-making process. Time for a change.

DESIGN THINKING

After nearly a decade of coding, I was faced with an opportunity to work in a Design Thinking role after a company-wide training resulted in the desire for more user research. This would be my first, major shift out of code and the announcement took people by surprise. I wasn’t worried about it. The fact of the matter was that I made a deliberate effort throughout my career to straddle the lines between disciplines and to maintain a well-rounded position on the software development spectrum. Instead of being further down the line towards the coding portion, I wanted to be in the discovery phase and learning what it is we should be solving. Same scale, different notes. Viewing the shift through that lens kept the “FUUU I’M THROWING AWAY ALL MY EXPERIENCE” notion from my mind. I knew code would always have a place in my heart and that side projects would keep me smiling. Plus, I knew I could still inform the coding portions, as I still had a grip of the code and possibilities. I founds this all to be an added bonus.

I spent nearly a year assisting the adjustment to the Design Thinking model. While the framework wasn’t fully embraced by all, the conversations did turn on some lights as to how far removed many of the decisions were from our users. Other noteworthy adjustments:

• Scrum masters and team leads emphasized the need for a “who” and “why” when writing stories or establishing sprint goals.
• Product owners were recognizing the benefit of different strategies and approaches throughout the development process.
• Sales representatives were listening 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, which was conducted in groups, and prevented one voice from declaring the takeaways. We were closer to objective data than ever before.
• Developers were questioning their approaches since 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.
• Tweet me for more examples!

Instead of coding, I was busy 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 to listen to what people are doing in their roles instead of asking for what they want, as humans aren’t always so great at building solutions for themselves. This strategy forced me to become more patient and thoughtful about client interactions. I’ve always been a rather fast-paced and “let’s jump to the solution!” person, but Design Thinking helped me maintain focus and attention to the details that aren’t so obvious. I enjoyed this new position and the speaking opportunities that came with it.

After about a half of a year, the common issue with frameworks in the workplace started to bubble up: people were focused on process instead of mindsets and the return on investment was in question. While I’m often the person harping “pay now or pay later” when it comes to research, I get that companies have varying degrees of table-flipping, product-changing opportunities. Subsequently, how you use the Design Thinking framework heavily depends on how much time and money you’re willing to throw at it. Results greatly vary. About a year in, I read the writing on the wall and decided to explore another role change. I knew I couldn’t go back to full-time development, but I also wasn’t sure that Design Thinking would be a viable role in every company. I needed to stay closer to the heart of the problems, too. I started to explore options that could melt all my favorite roles and interests together (if even possible!). Enter product ownership.

TECHNICAL PRODUCT OWNERSHIP

You made it! We’re at my present-day role. I have been a Technical Product Owner (official title, but PO works for now) for just over a year and have found myself challenged in a variety of ways since throwing myself to the wolves of corporate America. Some of you might be giggling, but the largest company I had worked for prior to my current 14K-employee spot was ~150 people. SO YEAH — this was quite an understated adjustment. I could (should) do a separate write-up about the realities of large companies and the necessary process changes for survival. I’m still judging whether I’m cut out for this type of churn or “corporate swimlanes,” but I can certainly appreciate the processes and visions necessary for keeping a giant company thriving and growing.

So what exactly does a Product Owner do? The answer comes down to the roles and definitions per company so I’ll leave that for you to research. In my specific role, I’m a glorified platform coordinator that communicates major changes outward while setting priority of work for my three development teams. Each team is comprised of a Scrum Master, Business Analyst, UX Designer, Solution Lead, multiple developers, and at least two QA testers. My job is to keep the team engines purring along and offering value to the company while balancing the workload to the availability of each member. Not all developers are the same! I, for one, appreciate the specialization of individual developers over forcing this interchangeable potential. This topic right here could be its own discussion, as the team compositions greatly impact morale, velocity, and quality. Hnnng I’ll resist the tangent for now. Back to PO.

As for the title, I do not feel like I “own” anything per say, as there’s no sense in calling a full platform a “product.” Instead, I opt to cross coordinate with my fellow POs, designers, analysts, and developers to reduce the siloing that can happen in large companies. I feel best at my job when I’m at the intersection of all these disciplines and catching a glimpse from as many of the angles as possible. I feel the worst at my job when trapped in a small box of expectations e.g. writing JIRA tasks when overarching, fundamental questions are unanswered. Did I mention I need the big picture at all times? Woops. The harsh reality is sometimes you’ve got to buckle down and get things out the door. I try to buffer those moments as much as possible. Otherwise, my days drastically vary since I’m sometimes deep in the weeds of ironing out code functionality or I’m way up high while imagining the future streamlining of platform integrations. This reality is both exciting and daunting; I like being able to anticipate my work, but I also require constant changes of scenery. Yes, I know this sounds needy, but what can I say? This is why I’m a big advocate for changing up roles and finding out what works best for your personality and skills.

I won’t sugarcoat the reality that the PO role is often a pinch point. Welcome to middle management! POs are an easy target for teams or management to point the finger or another link in the long chain of communication that can easily break. Additionally, the title “Product Owner” often suggests a level of decision-making power that is rarely the reality. I’ve had many moments of people looking to me for a decision, I make one, and yet get overridden by another decision elsewhere. It is what it is. I’m once again resisting the “large company dynamics” tangent. Stay focused, Kristen!

On the flip side, the successful coordination of POs can result in higher product and platform awareness through maintaining both the weedy and high-level goals. I have experienced moments of throwing flags on discussions that were missing vital information about the platform and very likely saved a huge headache down the line. This type of coverage is essential for reducing the churn and tech debt that is often generated by “move fast, break things” attitudes. A final note for my own agenda: I appreciate POs that can advocate for developers and the clear view of the systems that they have. I try my best to keep my dev hat as close as possible so that I don’t get too caught up in the business demands. Developers have a great pulse on the health of a platform so they cannot and should not be ignored even with the promise of a new, distracting product. Tech debt will catch up to you.

OKAY! That’s enough of my rambling. I am 1000000% sure I could write way more than this, but I’d rather shift to the questions provided by the wonderful Twittersphere. Thanks to all that contributed and feel free to add more if you’d like.

---

QUESTIONS

After being in one field for a while, you learn what it takes to be good at it. Has switching forced you to start over with that?

Definitely. There’s no escaping this, in my opinion. I could give you a classic job description for a Product Owner or even a Developer, but the reality of the company’s goals or day-to-day processes could result in different expectations or duties. Quite honestly, I attempted to follow the cues of one PO out the gate, but soon recognized that their style wouldn’t work for the types of teams I was leading. I eventually learned to trust my own judgement and people skills even though I sometimes went against the grain of existing expectations. I felt better once I “made it my own” and often remind folks to get to that point sooner than later. Important note: this role is rough for people pleasers. In the same vein, there are varying definitions of “good” when judging performance. All of this concern gets amplified when juggling multiple teams, but you get to know the peaks and valleys in time.

Relative to dev, what’s the job market like?

I’m not sure I could simply say! I did notice the difficulties when attempting to specify the layers of product management while interviewing — Product Owner, Product Designer, Product Manager, etc. The job hunt would quickly collide with Project Management, too, which is a whole other beast. All of this echoes the reality that these roles are often molded to fit the company and the requirements vary. My best advice is to avoid the assumptions and find out what exactly each title means for each company.

How did you know you wanted to switch? Were you bored with dev?

I did talk about this a bit in my career recap above, but I ultimately felt like I was too far removed from the decisions in the software process and constantly needed the bigger picture. I’ve come to learn that not everyone needs the “why” or reasoning behind a project ask, but I do. I implore anyone reading to figure out where they stand in those terms. Also, I’ll never grow bored with development. Coding is an area that requires the most flexibility and adaptation to change, as languages and frameworks are *constantly* evolving. While I do think I’m super compatible with dev, I think I can have more impact a little further up that spectrum.

Now that you’ve seen other parts of the business more closely, going to switch again?

Great question. I like the overlap of worlds at the PO level, but I do not feel as though I have the influence or power to direct changes like I could in other roles. I foresee a continuation down this path in search of more actual ownership.

Let’s say I’m considering the switch, how might I decide it’s a good idea?

Woof this is a tricky question. I don’t feel qualified to answer for you, but I can say that I see a leap of faith in the picture. Perhaps you can find companies that will let you dabble? I had to go through a three-month probation period (make sure it’s retroactively paid!) when I made my shift from dev to design thinking. That said, probation periods somewhat piss me off, as you’re often doing both roles during the transition. I could have benefitted from quitting and interviewing for the new role so that I could be paid the right amount from the start. Something to consider. I’m not trying to dodge your question as much as acknowledge the reality as everyone’s a bit different. I was convincing myself that my full-time dev years were behind me so that was helpful in keeping me focused.

What’s something you didn’t expect to be hard?

Easy: not being able to please everyone. I’m used to knocking my work out of the park, but the combination of having three, large, dev teams plus the learning curve of ramping up into a company I don’t know made for a tough success rate. I have learned to accept that my approach won’t please everyone, but that I need to stick to my guns since I know the role the best. I’m slowly finding that sweet spot.

Who is responsible for miscommunications between product and dev?

Ultimately, I think the PO needs to step up and own the communication to the developers and upwards from there. This doesn’t mean that the decisions made at the senior or management levels will always be right, but I do believe that a PO should be as transparent as possible about the decisions at higher levels. Alternatively, POs are the last-ditch effort of staying honest to the state of code before senior levels continue their higher-level assumptions. Herein lies the meaningful purpose of the PO.

We need to ship something yesterday. We know what dev is doing. What is product doing?

We’re figuring out the future impact of shifting developers from one effort to another. So much of my job is pulling levers to change the progress on features and what goes out the door. Understanding the priority of features is crucial as is keeping tabs on the necessary updates and tech-debt work that keeps the platform happy.

What are your deliverables? To which stakeholders?

My deliverables are features or platform changes that enable new possibilities. In my role, I can serve both internal, support users all the way to our external, end users. That said, my stakeholders greatly vary. I won’t say this is the norm for all POs, but most POs have to answer to Product Managers that dictate when and how features come into play.

Do you run experiments? If so, what’s the time to feedback?

Yes! We often run these as spikes in our agile process. Or we’ll take a few sprints to explore larger endeavors as a “quick turn” endeavor. I’ve had major product directions start as a proof of concept so never underestimate the power of some tinkering!

It’s shipped and you were wrong. How do you know? What do you do?

Ah, yes. You thought you were on the right path, but missed the mark upon release. We use our charters and the success criteria to gauge how we’ve done. The impact can vary by company, as mine tends to carry the necessary adjustments into future sprints. Meanwhile, I, personally, want to ensure that we’re paying attention to when and how we fell short so that we can avoid such pitfalls in the future. This leads back to my user research agendas, as we could potentially catch these details ahead of time.

To what extent should developers be involved in the product development process?

Ahhhhh this is a definitely a question that will show my bias. I wish for all developers to care more about the bigger picture and “why” we ask for various features, but not every developer is there. I do my best to respect the “I just do what I’m told” devs, but I think they’re missing out on the chance for greater impact. That said, I greatly depend on developers that speak up and showcase why a product direction is fundamentally wrong or poorly timed. I get anxious when developers are too late in the decision process for these reasons. TL;DR: please jump in sooner than later, devs!

How is the creativity of the job different? How differently do you need to be flexible? Original? Fluent?

I need to tap into my communication skills way more often, as I need other POs and departments to know what’s coming so they can weigh in. I have to be extremely flexible, especially as a PO for the platform. My personal goal is to be more visionary in the future, but I’m still learning the lay of the land this past year. I’m looking forward to “seeing” the potential and creating opportunities for the company.

Would love to hear how you started.

Great! Scroll up 🙂 Pretty sure my long-ass writing covered those bases.

What, if any, push back did you receive from peers (i.e. not management)? I find it’s harder to convince my peers UX is important but management seem ready to hop on the train.

Ohhh yeah. Trust me; I had my fair share of listening to “mehhhh UX doesn’t matter” while I was a dev amongst devs. I don’t mean to put developers on blast, but many of you don’t appreciate the level of detail that goes into making successful software. Sure, you can make things work at a functional level, but customers expect everything to work at an intuitive level! Simply aiming for true/false won’t do the trick. Honestly, this is why I started to shift from code, as I understood the human demand of the next decade. Functionality and a bottle of wine will not save you. Obsolescence will be the sobering reminder that you need to care about the human experience and build towards it to the best of your ability.

How did you approach design QA knowing that now you were asking a dev to do the work rather than yourself? What compromises were you to make? What didn’t you budge on?

Hah one of my fond memories was eventually giving a developer the coding solution to a problem I wanted him to solve. He thought he could pull the wool over my eyes and cut corners, but I took the opportunity to remind him that I knew exactly what to do in that scenario and that he couldn’t fool me. This was the first time I offered the “how” to my team, but it served as a proper ego check so that my developers didn’t think I could be easily swayed. Given that reality, I don’t budge on cut corners. I can see when developers try to take the “easy route” and convince POs that there’s nothing more to be done. Because of that, I greatly rely on my development history to hold these teams accountable to their decisions. They have to convince me, first, which guarantees that they’re not half-assing their results. I see it as a general improvement in the quality of the decisions being made.

Are you concerned that returning back to development might be challenging? E.g. coding skills and fluency atrophy.

Hell yes. I have the fresh memory of a recruiter telling me to not grow stale in my dev work after I told him I was now in the PO realm. I was immediately offended by the frank “don’t get rusty!” words, but I understand where he’s coming from. I don’t want to get too far removed from code, but I know that middle management in software can often result in so many wasted efforts. My heart breaks for the developers that pour into a project to only have it go to waste. I feel far more devoted to ensuring that code sees the light of day vs. my skills getting rusty so I think I’ve made the right decision in my career. This is why we have Udemy and other resources, right? I’ll spend a weekend sharpening my skills so I don’t get too far removed. I can’t say that every PO is doing this, but I think they’d help their cause to do so in order to maintain the modern expectations. Especially if they can keep from having their developers pull a fast one teehee.

That’s all for now!
I’m out of questions, but looking forward to more if you have them. I intend to treat this post as a living document so you’ll likely see more added on in time. I sincerely hope this helps in some capacity otherwise I just spent a lot of time typing into a void haha (wouldn’t be my first time).

Best of luck in your future endeavors, readers. Keep up the good work of making tech the more inclusive and awesome reality that I see for it.