Resources > Articles

How a Technical Background Empowers Product Professionals

Post Author
  • Scott has been helping companies achieve Software Product Success since 1997, and started Tyner Blain in 2005. Scott is a product management and strategy consultant, and a visiting lecturer for DIT's Product Management program. Scott has managed teams from 5 to 50, and delivered millions of dollars in value to his customers. You can reach Scott at scott@tynerblain.com, or join in the conversation on the Tyner Blain blog.  

technical

I’ve been asked repeatedly over the last decade if having a technical background is required to be successful as a product manager. The answer is no. But it has certainly helped me to be more effective. This is a personal and situational question which has no crisp answer—but sharing some of my experiences may help you to work more effectively with, or as, a product manager with a technical background.

technical
Photo By ThisisEngineering RAEng on Unsplash

Internal Wiring

I don’t know if I went to school for engineering because of how my brain was wired, or if Carnegie Mellon rewired my brain for me—but I always say it is where I “learned how to learn.” How I approach learning, and how I apply different analytical techniques to synthesis, situational analysis and development of insights is driven by how my brain is wired. In product-management speak, the way I learn things is a distinctive competence, and it makes me objectively better as a product manager. I would argue that this is because of my technical background. I would expect people with similar backgrounds to have similar advantages.

The Inside Track

I tend to work most frequently with businesses that incorporate software development into developing solutions for their customers. I happen to have also spent several years developing software—and eventually leading teams which were developing software. This arcane knowledge of the secret handshake has helped me develop effective working relationships with the team members who are actually creating the product. When you do something, you learn it more viscerally than if you only read about it. Building on this deeper level of insight, which only comes from doing, is one way to develop camaraderie with the team of people creating your product.

The Temporary Crutch

In terms of what you already know, a technical background only helps for a short while. Eventually, the information you acquired will become irrelevant—and eventually it will mislead. Imagine trying to apply pre-SQL database perspectives to conversations about NoSQL and distributed data storage architectures and the ensuing release-planning activities. You can also, of course, have a bundle of technical knowledge, which is not relevant to your problem domain. Bernoulli’s equation is not going to help me increase conversion rates on a website, or help me assess the value of continuous integration.

My approach to applying the things I already know—or used to know—is to leverage that knowledge for shared context in conversation, pattern recognition when being exposed to new-to-me information and generally applying the principles of learning to whatever is in front of me. I do not try to apply the knowledge to solutioning, beyond using it to guide some directed questioning or to help with hypothesis formulation.

One of the phrases I remember from Pragmatic Institute’s training was a question from my instructor: “If you are going to do their job, who is going to do your job?” That very question helps me walk away when I start to get too far down into the weeds in discussing how we’re going to solve the problems. It is a slippery slope, especially when you really enjoy technology and secretly wish you could be coding away (or designing or testing) with the rest of the team.

Helpful, with a Twist

The crux of it is that the benefit of having a technical background does not come from participating in the technical work, but from how it helps you collaborate with the technical team. Collaboration is a soft skill, and it is the one that is broadly helped by having technical wiring.

Sometimes, we work on products that are helping our customers to solve problems in a technical domain. In these cases, being technical can help quite a bit—and may even be genuinely required—in developing an understanding of your market.

Consider, for example, developing the staffing schedule for a large hospital. You need to be able to synthesize technical problems, combining the abstract mathematical problem (the nurse-rostering problem is a classic computational conundrum) with the business appreciation for defining the “good enough” solution. In my opinion, developing insights about how to compete in this market requires you to be able to appreciate the mathematical complexity of the value proposition, so that you neither assume it is trivial nor intractable. This is a problem that people will pay to solve. It is also a problem that requires a combination of technical solution and business perspective.

At the end of the day, if you’re developing a product that is addressing a particularly technical problem, I don’t believe you can be effective without sufficient “technical wiring” in your brain to be able to fully appreciate the challenges (and opportunities) in play. One of the better (and very technical) product managers I have worked with happens to have a degree in history, but his brain was absolutely wired to be able to think technically. Demonstrated success in a technical role (or education) is a likely indicator, but an imperfect filter.

In a Nutshell

Having an existing body of technical knowledge in your head is of limited and suspect utility. Limited because it is more useful in application than in collaboration, and suspect because it will become irrelevant or even wrong faster than you will expect. I think of this as a circumstantial outcome of having a technical background—not an asset that can be directly leveraged.

But even when you’re creating products that are not “technical,” having a technical perspective can help you significantly in the process of creating those products. And that’s not because it helps you do any of the technical heavy lifting, but because it helps you work more effectively with the people who are doing the technical work.
]’4701

Author

  • Scott has been helping companies achieve Software Product Success since 1997, and started Tyner Blain in 2005. Scott is a product management and strategy consultant, and a visiting lecturer for DIT's Product Management program. Scott has managed teams from 5 to 50, and delivered millions of dollars in value to his customers. You can reach Scott at scott@tynerblain.com, or join in the conversation on the Tyner Blain blog.  

Author:

Other Resources in this Series

Most Recent

Magnifying glass replacing the letter o in the word Job
Article

How to Maximize Your Product Job Search 

I am no stranger to the product job search. This journey has taught me a lot about navigating the job market, and that's what I want to share with you.
The image features the term use scenario being revealed underneath a ripped piece of paper
Article

What is a Use Scenario [ +7 Examples]

The purpose of drafting use scenarios is to help your development and design teams to start thinking about solutions. Context is the foundation of innovation, and you’ll be providing a tool that will be the starting point for collaborative and productive meetings.
Article

[Comprehensive Guide] Product Owner vs Product Manager

Learn how to separate the roles of product owner and product manager on Agile teams and uncover some common challenges with confusing these roles. Including a short primer on the Agile revolution.
Article

Use Scenarios are Stories That Provide Context

The problem with today’s user stories is that they aren’t interesting. And they aren’t stories. The solution is use scenarios. It’s a narrative. It explains the problem in the form of a real-life story.
Article

Benefits of Bundle Pricing

Bundle pricing is simply a strategy where services or products are packaged together for one (often reduced) price rather than priced separately. This article covers some benefits of bundle pricing followed by a system for getting started.

OTHER ArticleS

Magnifying glass replacing the letter o in the word Job
Article

How to Maximize Your Product Job Search 

I am no stranger to the product job search. This journey has taught me a lot about navigating the job market, and that's what I want to share with you.
The image features the term use scenario being revealed underneath a ripped piece of paper
Article

What is a Use Scenario [ +7 Examples]

The purpose of drafting use scenarios is to help your development and design teams to start thinking about solutions. Context is the foundation of innovation, and you’ll be providing a tool that will be the starting point for collaborative and productive meetings.

Sign up to stay up to date on the latest industry best practices.

Sign up to received invites to upcoming webinars, updates on our recent podcast episodes and the latest on industry best practices.

Training on Your Schedule

Fill out the form today and our sales team will help you schedule your private Pragmatic training today.

Subscribe

Subscribe

Training on Your Schedule

Fill out the form today and our sales team will help you schedule your private Pragmatic training today.