The role of Product Manager has been quite fluid ever since its inception.
Unlike career tracks like computer science or marketing, there hasn’t been a formal education path for the role. There’s no list of all the things that a product manager should do.
Ian Lotinsky, VP of Product Engineering and Design at Weld North Education, believes that’s because the role is shifting. Over the course of his career as an engineer and CTO, he has seen the evolution of various roles in the software field.
In this article, Ian shares his beliefs that there are distinct roles that product, engineering, and design teams should play.
The conversation below has been edited for length and content.
You’ve said that you feel the role of Product Managers is shifting. How so?
The software industry has changed quite a bit. Software Engineers used to spend a lot more of their energy thinking about how to just get computers to work.
There weren’t a whole lot of frameworks. There were some APIs you could use to print things on screens and create buttons, but the tooling to build software was less mature at the time. A lot of calories were burned just to get things up, running, and working.
Over the past 15 years, it’s gotten increasingly easy to build software – particularly web-based software. Software Engineers no longer have to worry about how to get a button to render or how to get a piece of code to run consistently across different browsers.
They can now think about the higher-order question: What are we actually trying to solve here?
Similarly, Product Designers also used to spend a lot of time in their tooling trying to get things to render beautifully.
Back in the day, it was drawing things in Adobe Photoshop and then cutting things to precise pixel points and trying to piece them together again in HTML (or later using some CSS). That tooling again has gotten much better.
The designers can now think about the humans who are going to be interacting with the software. They can think about the problem that humans are trying to solve with this software, and not focus as much on pixel pushing.
I believe the role of product management is to understand the human problems being solved. There is a finite number of resources and time we as companies have to build software or solve problems.
The most important thing the product management function can solve is prioritizing which problems to solve, and then letting engineers and designers figure out what the solution will be.
There is plenty of work to be done in terms of digging deep into those problems. Being judicious about the priority of those problems and creating a single list of jobs to be done to solve those problems. It’s a very arduous task.
Unfortunately, a lot of product managers try to be responsible for more than that. They try to get involved in the actual product design. They argue with the engineering team about how something should be architected or how the job should be done.
One thing that caused a shift in the Product Manager role was Eric Reese’s book The Lean Startup. It was about how companies should use data to learn whether they should pivot, persevere, or shut things down.
It helped define a path that the product team should take to make decisions. It changed from throwing stuff at the wall to a science.
Recently, there’s another set of books around the framework of “jobs to be done”. That has further refined what problems to solve and the order in which to solve them.
I see the product management role shifting from a loosely defined jack-of-all-trades to someone who is looking at the jobs to be done. Someone who sets the priority, collaborates with the engineering and design to figure out the sequence of solutions to be shipped, and then measures results.
They should look at the data, both qualitative and quantitative, and use it to bring the recommended priorities to the business leaders and engineering/design team.
Then let the engineering and design team solve them.
Engineers and Product Designers have had a shift in their responsibilities to think more about the higher-order issues.
That frees up the Product Manager to focus on the priority and the data that drives that priority.
What background do you think a product manager should have?
Most of the folks I’ve worked with had similar backgrounds. They might’ve had an I.T. degree in college or dabbled in a bit of software engineering, web development, or web design. But they didn’t make a career out of building products.
I know some folks have a requirement that product managers must be former software engineers or computer scientists.
I think the reason is because they understand the technology. So, when the engineering and design team says they’re making a certain implementation decision, the product manager can understand the implications of that decision.
It also helps with conversations around trade-offs. There is nothing more frustrating for an engineer than debating a decision with someone who knows nothing about why that decision was made.
I like the idea of product managers being former product builders, but I don’t know how many software engineers can fit in that role.
I’ve worked with some folks who can do it, but it’s really difficult to find someone completely well-rounded. Someone who can do software engineering, understand the business goals, and identify the jobs to be done.
There is wisdom and intuition that comes from focusing on the decisions that need to be made.
