It’s Product Management; not Software Engineering…
If like me, you don’t know your Kong from your Kubernetes and you think that TeamCity is your local football club, relax; it really doesn’t matter at all.
Making the move into Product Management can be a daunting prospect. The paths into it are few, and the natural consequence of this is that many new Product Managers find themselves thrown into an unfamiliar — and often terrifying — swamp of unintelligible jargon, dangerous acronyms, only to find themselves newly armed with an endless list of oddly named technologies and tools at their disposal. This may be particularly amplified for those who find themselves in Product roles at companies that still operate in the more traditional ‘Business Analyst/Software Engineer’ paradigm, where ‘requirements’ are cold-bloodily handed from one business unit to another.
For those then, like me, who do not come from an engineering background, the learning curve is steep. Not only are you now responsible for making strategic decisions about what to build and why, but you feel you are forced do so in an alien environment, blind, with your arms tied behind your back and with nothing but instinct, luck, and the ability to bullshit to guide you back to safety.
It can be quite a disarming sentiment, but if you sometimes feel like you’re up the proverbial creek, let me give you this helpful paddle; you don’t have to know everything about technology. In fact — and this is the fun part — there are people on your very team who get paid to know a great deal more about technology than you do, especially about how to utilise it effectively. Implementing solutions to the problems you need to solve, using the technologies available, is their primary domain. It’s what they are trained to achieve. It’s a skill that they have spent years developing and, in my experience, find a sort of perverted, twisted, fun in applying to real world problems.
Do you know who they are yet…?
You’ve guessed it; the Software Engineers.
At a Product Ownership event in London recently, I was surprised by the number of my industry peers who were more concerned with technical details than behaviour changes and outcomes. Some of these individuals were experienced Product leaders, yet, their focus on tech rather than shipping value was surprising to me.
The fact that others in my field [seemingly] had more technologically driven domain knowledge than me made me feel as though I was insufficiently able to do my job effectively. How could I possibly lead product design, when the very products themselves consisted of a complex network of logic beyond my current understanding?
Now that I have had time to reflect on that thought I have come to realise how counterproductive it is. Of course, you have to be interested in technology as this is the medium through which you are providing solutions, but you only have to understand what is possible and what is not. The granular detail of it all can be left to the experts, whilst you focus on doing what Product Manager’s should do; Product Management!
Here are a few helpful tips which may assist with any imposter syndrome that you are experiencing as a result of focusing too much on what you don’t [need to] know, and not focusing enough on the important and wide ranging skills that you provide to the Product Delivery Team as Product Manager. You know, the skills that got you where you are in the first place…
- Lead the Product not the Tech
It couldn’t be simpler, eh? The responsibilities of a Product Manager are well documented, but put simply, the role requires leading product design and development by creating products and features that will provide some form of (the rather ambiguously used term) value.
Your users almost certainly do not care about how the system is working, and so neither should you (to a degree…). Don’t forget, it is the users that you are designing for and this is what should inform your product strategy. Your role is to articulate their high level needs into workable and deliverable features. This involves understanding their pain points and communicating them to the engineers by creating user stories (or the method of your choice). Create empathy for your users within the team, create understanding about what you’re trying to achieve, and you’re doing the right thing.
Refine the backlog, understand desired outcomes, facilitate shared understanding with the team, and let the engineers discuss the technical design. Just as the engineers [won’t necessarily] know what to build next, you don’t [necessarily] need to know how what is to be built, will be (although you should know how you will expect it to behave!).
2. Embrace your ignorance
For me (after I had come to terms with my own perceived inadequacy) this really became the best part of not coming from an engineering background. The best way to earn respect is to admit what you don’t know. Feel that delightful warm ignorance flowing through your veins! Your contributions to conversations about how to solve problems will be way more valuable, and you can simultaneously relieve yourself of any concerns that you may have about not being a degree’d up engineer with X number of years experience at cracking code.
Facilitate good product design by offering a perspective that places the user above the technology. This will be provide the team with insight that turns their sheer guesswork into awesome products.
3. Learn, but Learn the Right Things
As I stated above, the learning curve can be quite steep. You will need to learn about how to create an optimised product delivery cycle, how to be ‘agile’, how to record and respond to customer feedback, how to prioritise features, how to measure success amongst many many others things. Not only that, but you will also need to understand the business context and create alignment within the team of the product strategy.
Becoming effective at the above is no trivial matter and could take a lifetime in itself. In fact, you should never stop seeking to optimise those skills. Your time is much better spent learning those endeavours over concerning yourself with how the code actually functions. That is, unless you actually want to be (or are!) a software engineer, in which case…
4. Know something about everything (and everything about nothing)
Tied into the above, you are the conductor and the rest of the Product Delivery team (you are not an ‘engineering’ team), well, they’re the orchestra. The conductor may not necessarily know how to play any instrument (I admit, I actually have no idea whether conductors are expected to know how to play, so I apologise if this analogy is a little loose with the truth…) but they do know how the instruments will work together. The conductor must know enough about the instruments to guide the many moving parts together into a functioning whole, and as Product Manager, this is your role, too.
Know enough to facilitate product discovery and design, but let the specialists worry about the implementation. Know enough to make sure that sufficient cross-domain knowledge is being transferred between parties and ensure that the right questions are being asked, and that the correct assumptions are being tested. Your role is to make sure that the right questions are being asked, and not necessarily to answer them all. Leave that to the ‘players’. And if you don’t know something…well…see point 2 above.
