Over the past year I’ve been spending some time in the subreddit r/ProductManagement and with my background of 10 years in Software Development and 3 years in Product Management, I’m happy to write where I can contribute. In this series, I’ll republish some of the responses I’ve written and maybe expand on them. This is part three, also checkout Part One on Team Culture and Two on Company Mergers.
Transition plan from engineering to product?
I recently applied for a PM role at my current company, and feel incredibly lucky that I was offered the role last week. I had a catch up with my new boss, and we discussed a transition plan, following the 10/90, 20/80 sort of idea. Problem is I think I can do that with engineering as I know where I need to be spending my time in the run up to transitioning, but with product I feel like I’m grappling in the dark, and can only suggest ‘doing product-y stuff’ (Key point to note my new boss hasn’t even confirmed the project I’ll be on yet, so nothing set in stone). Has anyone been through the same thing?
I did the same thing a couple of years ago. Everyone in our Product department was informed I’m new at the table and that I’d be splitting my time from now on. In our bi-weekly meetings and the upcoming OKR planning, I was introduced to the current topics and my engineering team lead and CPO/CTO paid attention to not overbook me. Research tasks can be a very good introduction as they allow you to get into a topic with fresh eyes, talk with people and start to build your network. Use the early time to dig into a lot of different stuff, shadow your colleagues and see what you find interesting and where you want to grow. Researching tasks are also great for networking and expanding your social circle. Also being a sparring partner for your Product colleagues is fun and a great way to learn. Look at data analysis together, design experiments and interpret the results.
I started the first 2 months at 15% time share in Product Dept, which then expanded to 30% and then 50% within the following 4 months. After that we kept it a double role with me refocusing depending on the ongoing topics. In my next job I went 100% on Product.
Software engineer asking, can a double role in Engineering and Product Management work?
It can work if the circumstances are right. I worked for over a year in a double-role as Senior Engineer and Junior PM with 50% share depending on the projects and priorities.
Some things/thoughts that helped in this setup:
- having CPO/CTO as the same person help
- being in a flexible company valuing your work and willing to provide opportunities to retain you
- the projects you do as PM should be different to the ones you develop on
- be transparent about your time and the hat you wear
- have your line managers always in the loop about your time allocation
- in turn, your managers should be well aligned between their priorities on when you should focus on an implementation and when it’s time for PM focus
- recognize when to hand over development topics because they outgrow your current capacities. You may be an expert in a certain system — if you are the only one getting asked to change it — involve other people as well and hand it over.
- your engineering skills may suffer, because you stop reading into the latest technologies but instead learn about PM work. It’s a different knowledge and skill set, and a decision.
- and finally this leads to a decision you may have to do eventually what you want to focus on.
I still enjoy programming and I’m happy to be able to do a bit of prototyping in my Technical PM role, but it’s not my main job anymore . It’s a tool you don’t forget but that may support you in your new responsibilities.
“Code review” for PMs?
I’m thinking loud today…
Developers have unfair advantage — they have same language across all of them (code) and because of that, they are able to reduce risk by doing code reviews.
Is there something similar for product managers and their decision making?
Of course, one level of review is discovery it self (interviews, prototypes, a/b testing…), but do you have something between PMs for example, so there is always somebody else from company who knows what is going on? Especially for junior ones?
In my last two companies we gravitated to a double-PM setup.
When I got into Product Management from Engineering, the main PM of the Product would handle the main streams with me doing initiatives on the side to offload some of her work. We’d have a weekly JF to sync topics and have a weekly informal 30min to exchange ideas, reality check, bounce/groom ideas, talk about stuff we learned in and out of the company. We’d pair on stuff where second pair of eyes seemed useful. This also brought the big advantage, that I was always informed about her initiatives which made handovers (for vacation) very easy.
In my current company, we explicitly have a double PM-setup in the Product team with me being the technical mirror to the initial PM who focuses more on stakeholder-management, UX and release plan. This is because the Development team we feed is in external companies and communication with the developers is indirect. This required a technical perspective to counter-balance. Perfect? No, but so isn’t the whole setup. And it works surprisingly well with both of us having our own initiatives and features to move forward. It always needs negotiation to be transparent about each others boundaries and which topics should belong in whose basket.
Software engineer here: we are migrating a huge app, our PM wants us to “read the old code to make sure we don’t forget any requirement”. Is it a common thing?
I’d rather call it a “cautionary time-boxed search for pitfalls”. Legacy apps have weird things in them you simply don’t know as a PM because they came before your time. Often are very obscure features or edge-cases. If these kind of surprises are discovered regularly, I find it a totally sensible approach to start a dedicated search and learn about these as preventive risk management.
What’s important is a clear task and time box. Be clear what you are looking for, what they should report to you and give a maximum time the engineers should spend on this. Be aware, this is not about finding requirements, but rather making unknowns know. A fact-finding mission.
When I was a developer, I’d do this with new features replacing the old, to know the intersections and dependencies. As PM, it can be still valuable when tracing issues. This kind of research questions in a small scale become more common and necessary if your development team is external and you do not groom the implementation tickets yourself.
What are some subtle red flags during a product interview that say “working here would suck”?
In my last job search, I always asked if a reduced time of 36 instead 40 hours per week is possible. One time my interviewer laughed in surprise and said “we expect more like 40+ hours” me: “40+!? oh you must be compensating that well!” interviewer: “well, we trust everyone looks at their hours and balances them off. Don’t worry, it usually won’t be more than 45 hours”. I asked if that isn’t bad for people with families and all they said was that “our developers are young, have no families and like it this way”.
Same company called itself Agile and I kept asking questions about how they live it and it turns out they have a 2 year plan, with 6 week release cycles and Agile is in name only.
Before I could decline the job, they sent a rejection only to offer a senior position three months later. That one I declined.
I always asked what the diversity situation in the company is. A) To get a feeling for their definition of the subject and b) their status and initiatives. In Tech, the situation is usually dire. The interesting part is asking what initiatives they are doing to improve. Whenever a company already says, diversity is “not a problem”, “they don’t see gender”, “there is nothing to fix” — It’s a huge red flag. As PM or Developer you are in a privileged position with a lot of freedom to pick jobs. A good question is also to ask how the company treats people in less fortunate positions. For example “What are the things you’ve done for your employees during the COVID-19 community quarantine?“
Also a red flag is when a company is too eager to higher. Take the time, have multiple talks, ask to visit them for a few hours upfront. If they want to hire you but don’t want to allow that, something is off.
Social Dilemma and Product Managers
I watched Social Dilemma on Netflix on the weekend; It certainly struck me as something to think about with new products and where they can go. Also, lots of the conversations are what I do every week.
How can we increase engagement?
What are the hooks?
So, some questions from me;
What is the role of ethics in product management?
Where do we draw the line?
Does it change the way you look at your current role?
Have you ever left a PM job for ethical reasons?
You should be aware of what the effects your Product can have or is causing. A “fun” exercise is the “Black Mirror Test” where you sit together with a trusted mutual and get creative into how harmful you could develop your product. What would you need to do to make the worst impact on the environment, society or personal health? Write that down. What you’ll find are some personal red lines you may not have been aware of before and you will be more conscious when you get into projects that touch these red lines.
When it comes to crossing these. As always, you can try to present alternatives, you can try and help build a version that is “not too bad” or you can step away.
Regarding The Social Dilemma, there is a great podcast dissecting it’s worn out and actually not so hot premise on 200 years of election hacking.