Can someone be both Product Manager and Software Developer at the same time in the same organization? If yes, how common is this?
– Amy Walker
Discussion
A] Echoing what’s been said already, I’d always ask why they need to be the same person. That will tell you something important about the maturity/funding of the organization.
Can they be the same person? Sure.
Can a sculptor also be a painter? Sure, why not?
Will they do both equally as well and with their full attention? Probably not.
– Damian Marshall
B] In specific contexts – absolutely yes. One that immediately comes to mind is a platform project, where one can be both developer, and a (technical) PM/PO for the project.
For customer-facing initiatives, this would be fairly uncommon, unless a consequence of some unfortunate staffing/funding situation (e.g. the PM quit and isn’t backfilled, so a member of a dev team takes on their role).
Why fairly uncommon? Because there’s a reason for the PM role – you don’t want a fox guarding the henhouse. Each discipline (engineering, marketing, sales, etc.), if given a chance, would run the product in a way that advances its agenda and goals. E.g., an engineer might over-invest in the tech stack and overkill the solution with some bleeding-edge technologies, unless kept in check.
– Nathan Endicott
C] Depends on the size of the company.
I started learning about the EOS business format and instead of an org chart, they use an accountability (roles) chart. So that as a small company grows from 1 person to many, the roles are covered and don’t overlap. EOS is a pretty popular business format with lots of free resources on YouTube and the EOS website.
English, Economics, Biology, Psychology, Philosophy, etc. I’ve even seen some with no degree at all.
If you are interested in small business (less than 100 employees), I recommend you check it out.
A pet peeve of engineers is when lead product managers present solutions instead of problems.
It’s annoying because an engineer has to decipher and reverse engineer what the requirements are. They’re meant to own technical implementation; lead product managers own things like problems, customers and strategy.
Not many lead product managers are aware they do this. The ones that are stop doing it and their working relationship with engineers improves.
As an engineer, I’d love to know things engineers say or do, habits or traits that piss off lead product managers that engineers might not be aware of.
– Jesus Rojas
Discussion
A] As a lead product manager myself I would love to give a list of requirements and have zero problem afterwards, but the reality is that sometimes some requirement just pops up after we start working on the feature. You do 100 alignments with stakeholders and they say it is okay, then when you change their system they come running for you saying something they did before is now not working and they need it back ASAP.
– Samantha Yuan
B] What do people mean when they say PMs should not offer solutions? I have never seen a successful team where PMs are not heavily commenting on work to drive the solution in a certain direction. I would say it is more of don’t jump to one solution before you have let designers and engineers explore different ones together with you.
However, if anyone argues the only thing a PM should do is to set requirements and let everyone else figure it out, then a PM should also be a very low-paid role. Any strategy consultant can do that.
– Priya Verma
C] @PriyaVerma, It’s a collaborative thing. As a PM, I shouldn’t be showing up to refinement with a mock-up that’s never been seen before, it requires lots of work between different sets of stakeholders.
As I progress through my PM career and am getting ready to move into a management position, what I have found is most efficient is clearly outlining the most important problems, working with designers and engineers on the core of the problems, and providing the voice of the customer, but at the same time not getting so hands on that I’m the one driving all the changes. I meet with these teams regularly and provide feedback, but my time is best spent out talking to customers and selling the product. You need to give your stakeholders the autonomy to experiment and drive solutions based on your input.
– Naomin Wosu
D] Engineers are really stakeholders. You could make the argument, but I disagree. I’m an engineer by the way.
I think most people are saying this because as a PM generally you don’t know shit about anything technical. You need to rely on your engineers to come up with a solution because you don’t really know the implications of your decisions. Generally speaking.
We want to bring on someone who will focus on training/product documentation (not really hardcore developer docs). I think that we might be able to hire an early-career product manager to help us with this while giving them the opportunity to work on lightweight product stuff and eventually grow into a senior product role. The advantage of having them work on docs, in the beginning, is that we need someone to help us catch up on a major backlog of docs and it seems like a great way to learn the product which should give them a good foundation when they step into more of a product-centered role. (Our founders will still own the product for the foreseeable future.)
Does anyone have experience/advice on hiring their first documentation or hybrid-product role at an early-stage SaaS business?
– Rob Martin
Discussion
A] Interesting concept! I think my only concern if I were in your shoes would be that your documenter isn’t yet a product expert. I’m unsure of the complexity of your Product but having someone learn through crafting product documentation could potentially be a recipe for a lot of confusing documentation. It might be good to start by involving the person in the product lifecycle and process BEFORE having them move into the documentation role. I know it seems like the opposite of what you were thinking but if your end goal is quality product docs, your best bet is getting your person fully ingrained in the Product first. Just my opinion on the matter.
– Naomin Wosu
B] I think there are two separate tracks here in terms of hiring. With the founders owning the product, you can still bring on your first PM to help. There you can have them structure the documentation as part of their role and it will be a great introduction to the product.
Magic hiring word is Associate Product Manager for that inexperienced talent.
On the other hand, if this is outward facing then you’re looking for a product marketer not a product manager. Technical Product Marketer or Product Marketing Engineer is the role that’ll do this. But, there’s an opportunity to really refine your copy and make sure your marketing is aligned with your product and that requires someone with experience so I would recommend avoiding hiring as a junior role.
– Donovan O’kang
C] Thank you for your feedback. I’m glad I asked the question to the group. The technical marketing concept is an interesting one and might actually be the right approach here instead of trying to go this hybrid route.
Since these docs are more support and in nature I don’t expect our dev team to own them. We’ve fallen behind on the docs as a whole because we’ve relied on just providing one-off support to help until now but the docs are as much a pre-sales tool as they are a customer support tool, hence a marketing function would make a lot of sense.
Although retention is widely considered to be the most important metric to get right when building (and investing in) a business, it’s also one of the least understood. Why? Because unless you’re a growth expert or an experienced investor, you’re often relying on anecdotes, dated blog posts, and misguided benchmarks. I ran into this problem myself many times when working with startups.
Once you get to even moderate scale, each of these lanes becomes highly competitive. In the case of paid marketing and SEO, you are competing for a customer’s attention. Paid marketing becomes a business model competition (who can turn this customer attention into enough value that they can bid more than anyone else for that attention), and SEO becomes a ranking algorithm competition (who can capitalize on their content in such a way that “deciders” like Google want to continue to send traffic their way).
Model Market Fit is the concept that your market (and # of customers within your market) influence your model. Your Model Market Fit hypothesis revolves around some simple math: ARPU x Total Customers In Market x % You Think You Can Capture >= $100M. Yet when you do this for a lot of early-stage startups the simple math tells you that you don’t have a $100M company. Here is how to use the Model Market Fit Threshold.
__________________________
If you enjoyed this newsletter, please consider sharing it with a friend by asking them to sign up here.
Who’s Prowess? We are optimist product managers, engineers, and educators working on creating a world where merit meets opportunity. On Prowess, aspiring and experienced product managers showcase skills, learn from the community, and connect with employers to advance their careers.