Do I think I’d be where I’m right now were I not a computer engineer?
- Product Management as a trade — As a product manager, the rule of thumb is that if you know everything about the product/domain/industry, then either you should be in a different role, go build a different product or start your own company. Product Managers are not expected to know everything. What they’re expected to do is to harness the collective intelligence of the team to bring your end vision to life.
- Product Management as a leadership role — As a product manager, you’re not building the software, nor designing the UI and in most cases, not even marketing/selling the product. Your job is to serve your team, to bring them together in order to make the product happen. You’re supposed to set the vision, direct the team in the strategic direction you wish to go and do everything in your capacity to build & launch a product that nails the user’s job — to — be — done. In essence, you’re leading the team rather than working in a silo.
- Product Management as a learning ground — As a Product Manager, you need to be able to learn continuously — new domains, new industries, new products, new markets, new contexts, new usecases, new competitors. Hence you should be able to pick up the basics of software — APIs, web-interfaces, debugging, code commit, continuous integration, datafeeds and integrations, CSS, software architecture, velocity and more — with a few online or offline courses, thus continuously learning and adapting (having a learner’s mindset and technical curiosity). You’d be able to pick these things up even as you converse with your team day in and day out, solve different challenges, brainstorm and listen to your dev partners.
- Product Management as an Architect — Just as an architect doesn’t know how to physically construct a building, but understands enough to be able to plan, design a solid sound blueprint for it and review the construction thereafter; so does it help a Product Manager to know what’s going on inside the product / even understand the mechanics of the solution being built without having to know the code line by line. First and foremost, product managers are tasked with defining the why of the product. It’s essential to first understand the target market (the who), the problem and hypothesis (the why & the what) and then collectively decide how to solve the problem (better yet, leave the solution to the experts — design and dev).
So you see from the above that Product Management and technical skills have a relevant but a nice — to — have connection. It definitely helps to do some technical analysis, baseline technical estimates and understand the logic behind the technical challenges, but it won’t block somebody who does not have a technical background from doing their product job, if they’ve a humble learner’s attitude towards their trade.
What to do if we don’t have technical experience/skills -
- Have Technical curiosity — be it talking to your dev team, taking online courses, learning on your own, attending tech events, paying attention in all dev conversations/meetings, asking why and digging deeper into the answers provided by your dev team.
- Build working knowledge in these areas — rough technical estimates, high level product / solution architecture, Data collection/extraction analysis, Interactive prototyping, how the system is organized so that you know if a change in one part affects another part of the system, benefits of switching over to a new technology or programming language/newer versions of the current tech, software development process.
When you might need a technical background as a Product Manager?
- A hard core technical product where it may become difficult to understand the user painpoints/requirements if you do not already come from that domain/field — eg. semiconductors, tesla, spacex rocketships
- Deficiency in the technical team where you might have to step in to fill that role every now and then — eg. at an early stage startup
- Expectation from the senior execs that the Product Manager should be able to foster respect and understanding with the engineering team in order to be able to understand their limitations/constrains and hence better — utilize the team.
- Companies that mandate you must have a technical background — many of the FAANG companies have this restriction.
Other considerations / questions to ask yourself :
- Learning SQL for data instrumentation & analysis
- Tshirt sizing for triaging bugs and stories
- Saving engineer’s time and reducing their context switching (on doing analysis, estimating, basic patterns of bugs etc.) if you have a high level understanding of technology
- Environment setups (local dev, staging, production) and deployment
- Setting up data for testing and UAT, resetting data on testing environments without having to rely on QE or engineers
- Understanding technical debt and how the codebase is setup
- Staying on top of latest development in technlogy — upgrading
- Cost-Benefit analysis of different technical solutions
- Experimentation (A/B testing)
- Expectation management with business stakeholders — to be able to communicate or brainstorm a sound decision without having to play the middle man between your engineering team and business.
- Negotiating with engineers — does it help when you yourself have been a technical resource previously?
Do you think Product Managers need technical expertise? Let me know your thoughts below.
Join me as I discuss this and a lot more at the ProductTO workshop this Thursday Jan 24th, 2019 at TWG (The Working Group), Toronto.
