The multi-disciplinary nature of product management is what makes the profession so appealing to big-picture thinkers. Because they are unabashed generalists, PMs must become comfortable wearing multiple hats to solve problems. On a daily basis, they may need to communicate with design professionals, developers, business stakeholders, analysts, and possibly customers themselves. It cannot be overstated how important an expansive mentality is to building compelling products for customers, as there might not be anyone else in the organization who is able to answer as concisely the question of “What do our customers need?” as the PM.
Yet, PM generalists may find themselves at a disadvantage in situations requiring a high level of technical expertise. Luckily, there are ways to mitigate this problem.
Explain It Like I'm Five
We’ve all heard it before–that there are no dumb questions. Saving Mr. Rogers’ platitudes for PBS, whether this assertion is actually true doesn’t matter. As a PM, you must get comfortable doing nothing but asking dumb questions, all day long.
Unless you are a technical product manager, you have not been asked to develop the product because you have deep technical expertise. Rather, you have been placed in your position because you understand how to apply a problem-solving methodology to a set of facts and work toward its solution. You are a creative, big-picture thinker who can speak to all facets of the organization. You keep abreast of industry trends and what your competitors are doing. You are an expert communicator and problem-solver. But outside of the specific expertise you have in product management, you are not an expert in a traditional field. And that’s by design.
When we run our sprint demos, there’s a question I am fond of asking that many of my colleagues hate:
“In a single sentence, can you explain what solution you’ve implemented?”
Now, this is a difficult question for anyone to answer. But, ask this question to a software developer and you’ll wait an eternity as they jostle and clear their throats. Perhaps it is human nature that, no matter what role we have, we all want to justify our importance. Asking a specialist to give you a one-line answer is like asking a canary to stop singing; because specialists exist to uncover and analyze the various facets of the problem that (presumably) you do not have the skill level to do, you are essentially asking them to betray their very raison d’etre.
But asking this question is part of your job because you have to distill this information, decide what is important, and share it with stakeholders. You are the glue holding together the tactical solutions being made by specialists and the strategic decisions to be made by executives.
For example, there was a longstanding debate our team was having with enterprise architecture about how we would pull in certain pieces of customer data (like account balances, rate of return, etc.) into the user interface. There was a new data layer being built by the architecture team that wouldn’t be ready in time for our launch date, putting some of our features at risk. Our team watched a presentation about how this new system would work, when it would go live, and how it was going to change the world. Yet, in speaking with a colleague later, we both found ourselves unclear about what new functionality it would actually change in our web experience.
“In the simplest terms, can you guys explain what this is going to do?” we asked.
“Sure,” the replied the lead architect. “Now, your customers will see their balances dynamically updated in real time instead of twice per day.”
Bingo. No technical jargon, no insider lingo. That was all we needed to hear.
Seek Practical Knowledge
“Can You Give an Example?”
One subject in web design is CSS. Without getting technical, CSS is how the code of your website styles the elements of the page. It can help you universally apply colors, fonts, and margins, thus saving your developers time. Suppose you were new to web design and needed to learn about what CSS does. Do you necessarily need to know how it works? Probably not–you’re not coding it. It’s a great skill to have, for example, if you need to diagnose a problem yourself. But it isn’t mandatory for a PM. How would you learn the essence of what CSS does?
“Hey Piotr, I need five minutes of your time. Can you show me what happens to the page when we change the CSS?” You’re looking for the end result here. The key takeaway should be something like “CSS = page style.” When in doubt, ask an expert to draw a parallel between the current state of affairs and a past project. Have them pull up an example of when a CSS failed, or something wrong happened. This will give you an idea of what an ideal result looks like.
If you find yourself relying on the same person to teach you new things, it is possible that this relationship will grow into a mentorship. People who are good at their jobs love talking about what they do. And contrary to popular belief, mentorships are not formal arrangements. Finding a mentor can be as simple as calling a developer and asking him to show you where he develops the code, and how the code is shared. Ask if you can watch him work for 20 minutes. People are usually flattered to show other people what they do. Just be prepared to provide value of your own so it isn’t a one-way street.
Seeking practical knowledge can be a quick and effective way to learn about new subjects as a PM.
When in Doubt, Delegate
I keep hearing I’m the “CEO of my product” according to PM blogs. I’m not entirely sure about that comparison, but it’s an interesting one. Let’s assume that actually is the case–that I ultimately call the shots on my product vision without the interference of scope creep, budget cuts, or many of the other pitfalls that often arise. It seems that one of the cool things about being a CEO would be delegating work you don’t want. So, let’s talk about that.
One of the most important things a PM can learn to do may be new for someone with no direct reports working in a flat, matrixed organization: trusting experts. Yes, I know that sounds quaint given our society’s increasing hostility to expert opinion. To make matters worse, it’s your derrière on the line if the product fails. Why would you count on other people to do work for which you don’t have the time, knowledge, or desire? Because you have no other choice. A seasoned PM is an expert delegator who is comfortable accepting the analysis of an expert and using it to make a decision.
During one of my projects, a debate erupted between two senior developers. They were arguing about how to implement an API to allow an important piece of customer data to be passed from the database to the user interface. For ten minutes they battled about who had the most elegant solution to the engineering problem. The team was at an impasse about how to proceed. Since I am not a software developer, I can only evaluate their merits based on logic. So I pitted them against each other to see what would happen.
“Vamsi, what’s the main advantage of your solution?” “Cost,” he replied. “It will save us money.”
Then, I turned to the other developer. “Phil, what’s your main advantage?” “Speed,” he answered. “It’s the fastest way.”
They were busy digging in the weeds and I was trying to see the forest. We had a deadline coming up and were running a budget surplus. While both approaches were technically correct, it was Phil’s solution which we needed to implement at that specific juncture of the project. I made the decision on the spot and we moved on.
By delegating the analysis to experts, you are better equipped to make the correct decision.
Conclusion
As the connective tissue between functional groups, most PMs are communicative, well-rounded, multi-disciplinary professionals who dart back and forth between design, development, and the business. As generalists, it’s important for PMs to be honest about what they know and do not know.
To mitigate your lack of subject-matter expertise, PMs should (1) ask experts to break down the material in the simplest terms possible, (2) seek practical knowledge wherever possible and focus on what an individual technology accomplishes, not how it works, and (3) delegate tasks to others, which allows you to focus on the immediate task at hand while letting in experts to do the technical heavy lifting.
Who knows, you might become an expert in the process.
