PRODUCTHEAD: How technical does a product manager need to be?

i might be a product manager #

---

tl;dr

Developers and managers often have conflicting views of what constitutes value in software

Software engineers should ideally understand both what they are building and why

Unforeseen edge cases can cause headaches at roll-out, but provide valuable lessons

---

every PRODUCTHEAD edition is online for you to refer back to

hello

A common question I’m asked by both existing and prospective product managers is: “How technical do I need to be?”

As you might expect, the question typically comes from people from non-technical backgrounds. My short answer is that product managers need to know enough to be able to call bullsh*t when they hear it. Or to put it slightly less indelicately, to know enough to have a sensible conversation with a developer or engineer about the approach they’re taking, why they’ve decided to do that, and the trade-offs involved.

How much do you need to know to have that conversation? #

A common trap is that everything looks simple to the uninitiated — especially if you work with experts who make complex things look easy. (“Surely we can just change this in the product — it can’t be that hard!” Yes, it really can.) Nevertheless, I don’t believe you need to be able to write code to understand where a developer is coming from.

Before you begin to understand why some things are more technically challenging than others, I think you need to appreciate at a conceptual level the purpose, function, and limitations of each of the major components that make up your product. There will inevitably come times when you have to dive a bit deeper into how these things work with your team, but you’ll do this as needed.

There will be situations where the bar to even a conceptual understanding is set very high. You typically see this for highly specialised products, designed for use in highly specialised industries such as pharmaceuticals, semiconductors, and in the creation of artificial intelligence and machine learning models. In these cases it is not unusual to need a Ph.D. just to understand the purpose and benefits of your product for its users.

It’s not impossible for you to work in these companies, however they will reasonably expect you to have a deeper subject matter expertise than for more general-purpose products.

Should a product manager learn to code? #

Would it help if you did learn how to code? It rather depends on how far down that rabbit hole you wish to go.

In spoken languages, you can typically learn to ask for directions or order a sandwich relatively easily. But you’d be unlikely to pull off an improvisational comedy set in that language later that night.

In other words, unless you devote enough time and effort to becoming an expert yourself, you’re not really going to appreciate the nuance that your developers have spent years studying or gain the empathy you’re seeking. And if you did go off and do that, then you’d likely end up as an expert more in software engineering than product management.

Gaining even a conceptual understanding of the technologies in your product will take some effort. It will of course help if you have an ally in your engineering team who can patiently explain their approach and the workings of your product to you in terms you’ll understand. You’re also going to have to read in to the subject. Rather marvellously, there’s no shortage of people blogging or contributing to Wikipedia entries (which tend to be stronger on technical subjects), so there’s little excuse not to start learning.

The practise of software development is only one side of it. If you want to understand more about the mindset of your development team, seek out a copy of The Mythical Man-Month by Frederick P. Brooks, Jr., ideally the more recent anniversary edition from 1995. Despite its age, it is still largely relevant to modern software development.

Help! Everyone knows more than me #

The nature of product management is that you will interact with many different disciplines. The advice above focuses on software engineering, but could apply equally to any of the specialist disciplines needed to create, market, sell and support a product. Each specialism requires a certain depth of study and understanding to appreciate its nuance.

Remember: a product manager is a generalist who relies on a team of specialists to make the product happen. Just because you can knock up a wireframe doesn’t make you a designer. Likewise, talking to users doesn’t make you a user researcher. You’re not meant try to fulfil all these roles by yourself. You will have neither the time nor the depth of experience to do this successfully.

Prior to becoming a product manager, people tend to fall into one of two camps:

they might have studied a vocational subject, and gone on to work for a while in that specific discipline. If this reflects your background, then at the start of your product management journey you’ll be unfamiliar with most other disciplines; or

they might have worked in an organisation in which they helped with many varied tasks such as customer support, user training, tweaking the corporate website, and so on. If this sounds a bit like you, your experience will be limited to those specific tasks and be superficial at best. Don’t mistake this experience for expertise.

It’s perfectly normal to start out with gaps in your experience, both of product management and of other disciplines. Yet many product managers I speak to often feel intensely pressured to know every aspect of every discipline on their team inside-out, despite being relatively new to the job. Imposter syndrome abounds.

Relax. We all have to start somewhere.

I’ve spent my career so far seeking product manager roles that would help me fill the gaps in my experience. I’ve worked for:

a small company scaling up to learn about the challenges of growth, and how companies change and evolve in response (although I only realised this afterwards);

a large multinational corporation in the hope of learning how product management was done properly, only to realise that they knew less about product management than I did;

a hardware and software company to learn about team leadership;

a company in which I could learn more about the financial, commercial and contractual considerations of my products;

organisations that highlighted the importance of user focus and introduced me to truly empowered and multi-disciplinary teams; and so the list goes on.

Product management will continue to evolve new approaches and, in turn, knowledge gaps will open up. There will always be something new in product management to learn — and for me that’s part of the attraction.

Final thoughts #

It’s only to be expected that you’ll start out not knowing much about anything. And just at the point when you start to feel you have a handle on things, you’ll change product or job (or both) and you’ll suddenly feel way out of your depth all over again. Don’t panic! Success in product management is rarely governed by how much you know. Instead, it’s about how quickly you can learn and adapt. It’s this rate that will determine how well you progress.

This week I have some articles and blogs for you that will provide a perspective on software development, by software developers.

Speak to you soon,

Jock

---

---

what to think about this week

Coding Horror

Jeff Atwood is a renowned software developer. He co-founded Stack Overflow with Joel Spolsky in 2008 as a means for programmers to share their knowledge with each other. Its runaway success inspired many imitators of the format.

If you want to learn about software development, Jeff’s long-running blog, “Coding Horror”, is well worth a read in its own right. A particularly good place to start is his recommended reading list.

Coding Horror

“Recommended reading for developers” by Jeff Atwood

[Jeff Atwood / Coding Horror]

Joel on Software

Joel Spolsky is another famous face in software development. He is the co-founder of influential software companies such as Fog Creek Software and Stack Overflow, and has been blogging about software development since 2000.

As you can imagine, he’s covered a great deal over the last 20+ years. I think the script of his talk to students at Yale’s Computer Science department is an apt starting point.

Joel on Software

“Talk at Yale”, parts one, two and three, by Joel Spolsky

[Joel Spolsky / Joel on Software]

---

---

Engineering blogs by Wise and Netflix

I really enjoy blogs written by teams working at large organisations, particularly when they (broadly) bypass internal censorship and write honestly about topics they’ve found both challenging and enlightening.

Understandably, many of the articles on these two blogs are written for other software developers about complex problems and their approach to solving them. Some of the articles are geared towards novices. Others provide insight into the culture of large software engineering teams working on high-profile products at scale.

In particular, Wise’s engineering team sets a great example to all those organisations that don’t believe in the merits of cross-functional, user-centric delivery teams.

Wise Engineering blog

“What is product engineering? Our engineers explain” by SharonAnneKean, Wise Engineering

Netflix Technology Blog

“Bringing rich experiences to memory-constrained TV devices” by Jason Munning, Archana Kumar & Kris Range, Netflix Technology Blog

[Wise | Netflix]

Product management in ML / AI companies

Do you need to be a domain expert to work in product?

Let’s have a look at Jua.ai the product which I’m leading right now. We have an ML-based weather prediction model which claims to produce weather forecasts better than what the industry has otherwise.

[PAYWALL] What it takes to create (not license) your own AI / ML product

[Leah Tharin / Leah’s ProducTea Newsletter]

recent posts

Should I take a product manager job in a sales-led company?

Hi Jock,

I’m currently applying for loads of product manager jobs. I’ve received an offer from a sales-led company where the Product team reports in to Sales. Should I take the job?

Demonstrate good practice AND deliver good product

[I Manage Products]

Control your narrative

Years ago, someone once told me that “perception is reality” when it comes to reputation at work. Of all the lessons I’ve learned in my career, this has been by far one of the hardest.

How to regain control

[I Manage Products]

Why can’t I rely on user research from other departments?

Hi Jock,

You talk about doing user research directly with users – does it matter that the Operations and Process tracks are telling me what their users want instead?

The problem with proxies for your users

[I Manage Products]

PRODUCTHEAD is a newsletter for product people of all varieties, and is lovingly crafted from a thoroughly dismantled chest of drawers.