The phases product teams go through(firstround.com)
firstround.com
The phases product teams go through
https://firstround.com/review/how-to-craft-your-product-team-at-every-stage-from-pre-product-market-fit-to-hypergrowth/
6 comments
I have worked with a lot of product managers, but I still find myself unable to understand what value they bring.
It increases the distance between the engineers and customers. This eventually leads to making wrong short term decisions because PMs do not understand how to actually build a product. I had better experiences when engineers made product decisions.
Sounds like you’ve worked with a lot of sub par product managers then. A good PM is extremely good at identifying the actual problems you need to solve, the ones that can make a true impact on the business strategy you’re executing. Bad PMs just chase feature after feature, without identifying the impact they can/can’t make.
A good PM also brings in engineers to meet customers frequently, so long as it respects the engineer’s schedule.
A good PM also brings in engineers to meet customers frequently, so long as it respects the engineer’s schedule.
Possibly for very technical products, an engineer could be more impactful than a PM - since engineers could be their customer.
In most all other regards, I can't fathom how a proper engineer makes a better PM. I would suggest either: your personal product engineering skills might be higher than average, or the quality of PM's you have worked with is lower than average. Engineers typically are more interested in: frameworks, languages, algorithms, performance, technology of the day, etc - rather than the customer experience, messaging, ease of use, and business value brought to a customer.
Context: CompSci background, built lots of products, founder through Series C companies.
In most all other regards, I can't fathom how a proper engineer makes a better PM. I would suggest either: your personal product engineering skills might be higher than average, or the quality of PM's you have worked with is lower than average. Engineers typically are more interested in: frameworks, languages, algorithms, performance, technology of the day, etc - rather than the customer experience, messaging, ease of use, and business value brought to a customer.
Context: CompSci background, built lots of products, founder through Series C companies.
> Engineers typically are more interested in: frameworks, languages, algorithms, performance, technology of the day, etc.
As a software engineer myself, I think I'd go mad if I had to work with fellow engineers who were that stereotypically one-dimensional. Frankly, even the nerdiest of kids whom I went to college with that chose to present themselves as such had broader interests than that. I got into this field myself because I liked solving problems and was half-decent at doing so with math and computers, which hardly excludes caring about customer experience, messaging, ease of use, and business value.
If I'm choosing to work at companies with products aligned to my interests and values, and if my day-to-day work actually matters to the success of the product, why would I not care about customer experience, etc.? The success of the product or project will ultimately reflect on me, so frankly, I'm going to have strong opinions about what work the PMs are trying to push on the team (maybe not literally push, but at least pressure) and how that work is then communicated back to the customers and stakeholders. The engineers who don't learn to give a crap about all that are setting themselves up as sheep.
As a software engineer myself, I think I'd go mad if I had to work with fellow engineers who were that stereotypically one-dimensional. Frankly, even the nerdiest of kids whom I went to college with that chose to present themselves as such had broader interests than that. I got into this field myself because I liked solving problems and was half-decent at doing so with math and computers, which hardly excludes caring about customer experience, messaging, ease of use, and business value.
If I'm choosing to work at companies with products aligned to my interests and values, and if my day-to-day work actually matters to the success of the product, why would I not care about customer experience, etc.? The success of the product or project will ultimately reflect on me, so frankly, I'm going to have strong opinions about what work the PMs are trying to push on the team (maybe not literally push, but at least pressure) and how that work is then communicated back to the customers and stakeholders. The engineers who don't learn to give a crap about all that are setting themselves up as sheep.
> I would suggest either: your personal product engineering skills might be higher than average, or the quality of PM's you have worked with is lower than average
Another possibility is we're honest with ourselves is that the PM has a skill that you do not, and therefore you do not recognize the skill in action, and perhaps don't have the business acumen to understand the positive results it brings about. For example, a decision that seems short term may be made because of the opportunity cost that buys progress in another area.
Another possibility is we're honest with ourselves is that the PM has a skill that you do not, and therefore you do not recognize the skill in action, and perhaps don't have the business acumen to understand the positive results it brings about. For example, a decision that seems short term may be made because of the opportunity cost that buys progress in another area.
I’m curious about which type of products you have been working on and what type of product decisions the engineers you have been working with have done. Because your experience is the opposite of mine. Engineers who understand anything to business and product management are extremely rare. And people who are good at it and genuinely interested in it usually move to this role (or create their company!). Also, as described in this article (interesting read btw), a lot of PMs are actually just projects managers instead of being product managers. They plan small features here and there, add tasks to the sprints and attend daily stand ups. This is not what you want from a PM. You want a PM who has a vision for the product and a very good understanding of the market, the clients and the users (can be different persons in b2b), and the competition (like the founders in the first phase of a startup, who eventually need PMs to do this part of the job. This is also well described in the article). Finding good PMs is hard tho, there is no specific degrees or whiteboard exercises to differentiate the good ones from the bad ones. It’s all about experience and finding someone who already did the job correctly somewhere else.
> I’m curious about which type of products you have been working on and what type of product decisions the engineers you have been working with have done.
IME: technically-trained PMs are worth their weight in gold. PMs without a technical background are extremely dangerous liabilities.
Context: Mostly b2b products where careful judgement on technical feasibility is the difference between "useless" and "game-changer".
> Engineers who understand anything to business and product management are extremely rare. And people who are good at it and genuinely interested in it usually move to this role
It depends. Only if they don't take a huge paycut by moving into the PM role, and only if the org is willing to let them move into the PM role.
Many business are not willing to lose highly productive engineers with niche skillsets and are not willing to pay PMs as much as they pay their senior engineers.
IME, senior engineer -> executive/founder is a lot more common than senior engineer -> PM. But it's not because engineers can't be product people... sorta the opposite.
> a lot of PMs are actually just projects managers instead of being product managers.
No true Scotsman, right?
IME: technically-trained PMs are worth their weight in gold. PMs without a technical background are extremely dangerous liabilities.
Context: Mostly b2b products where careful judgement on technical feasibility is the difference between "useless" and "game-changer".
> Engineers who understand anything to business and product management are extremely rare. And people who are good at it and genuinely interested in it usually move to this role
It depends. Only if they don't take a huge paycut by moving into the PM role, and only if the org is willing to let them move into the PM role.
Many business are not willing to lose highly productive engineers with niche skillsets and are not willing to pay PMs as much as they pay their senior engineers.
IME, senior engineer -> executive/founder is a lot more common than senior engineer -> PM. But it's not because engineers can't be product people... sorta the opposite.
> a lot of PMs are actually just projects managers instead of being product managers.
No true Scotsman, right?
PMs are ideally senior engineers who've learned how to communicate with customers, salespeople, and clients (both senior management and end-users).
Unfortuantely, many companies/projects/teams don't budget properly for the PM role and you end up with MBAs or other non-technical business folk, who are often 1/3 to 1/2 the price of good technical PMs.
Unfortuantely, many companies/projects/teams don't budget properly for the PM role and you end up with MBAs or other non-technical business folk, who are often 1/3 to 1/2 the price of good technical PMs.
as an engineer I can function ok in a PM context. actually appreciate seeing how the product is used by the customers, and understanding the strategy of the business and exploring the options.
would I rather have a competent and responsible person to keep track of all that and drive the necessary compromises?
hell yes.
would I rather have a competent and responsible person to keep track of all that and drive the necessary compromises?
hell yes.
Knowing how to build something is only half the battle, you have to know what to build also. Engineers don’t tend to perform this function well (at least, not while also being effective engineers), so PM roles are meant to bridge the gap. It can work pretty well, but like all roles it can be done poorly.
People who can both figure out what and how to build are rare. To compensate for this those responsibilities are often split within product teams.
But if you can find people who can service both tasks at a high level then all the better.
And if you’re lucky enough to find someone who can do those things AND sell at a high level too then get behind anything they do, because you’ve got yourself an incredibly rare creature that can make a path through darn near anything and come out dry on the other side.
But if you can find people who can service both tasks at a high level then all the better.
And if you’re lucky enough to find someone who can do those things AND sell at a high level too then get behind anything they do, because you’ve got yourself an incredibly rare creature that can make a path through darn near anything and come out dry on the other side.
Product Managers keep the ship running and evolving once original breakthru and direction PMF (product-market fit) has been found.
The article has a nice context for Project Managers helping to execute on the original R&D to find PMF. I like that idea a lot as project management in general can speed up iteration greatly.
The article has a nice context for Project Managers helping to execute on the original R&D to find PMF. I like that idea a lot as project management in general can speed up iteration greatly.
Massively long article, but good enough that it kept me reading to the end.
Having a clearly rationalised summary of what a product team is for, and roughly when to introduce it, is an invaluable reference when transitioning from the "drunken walk" phase with a first time founder.
Having a clearly rationalised summary of what a product team is for, and roughly when to introduce it, is an invaluable reference when transitioning from the "drunken walk" phase with a first time founder.
Looks like Kent Becks' Explore, Expand, Extract: https://medium.com/@kentbeck_7670/fast-slow-in-3x-explore-ex...
A rare read in it's usefulness to know what gear you are in and how to build and execute around it.
Helped me remember:
- every good project/product I've worked on that has scaled began as something small and messy until.. it was less messy and less small by each iteration.
- having a team to innovate, startup, grow, and scale are often different teams.
- made some great points for providing opportunities to junior team members and not only experienced ones. People leave regardless but the ones who stay will be great.
Helped me remember:
- every good project/product I've worked on that has scaled began as something small and messy until.. it was less messy and less small by each iteration.
- having a team to innovate, startup, grow, and scale are often different teams.
- made some great points for providing opportunities to junior team members and not only experienced ones. People leave regardless but the ones who stay will be great.
Good indeed! I recommend reading if you are running a team and growing.
I found that page very difficult (impossible) to continue reading due to the various popups (social propagation buttons) and inserts (must read article thumbnails) that fade-in while scrolling down. The content doesn't match the delivery device.