Hi Doug (and, this being my first post, hi everyone!),
I’m product manager, product owner, and developer of an informal tech entity that will, hopefully, become a customer co-op.
I was a product manager in a couple of orthodox tech companies prior to resigning. And, prior to that, a program manager, a support manager and a sysadmin. I cite my history because in my experience ‘product manager’ is a flexible label in the tech world. All or part of its deliverables are sometimes hidden in ‘program manager’ and ‘support manager’ roles, particularly in dev or service-oriented tech companies.
My career evidences the issues identified in this thread.
I agree with columbene that product managers can be mini-boss - as can program managers. In my experience, this is particularly true in high profile companies, American(ised) companies and marketing-driven companies. An influencing factor in this may be that entities that are hard departmentalised (ie into ‘Finance’, ‘Sales’, ‘Marketing’ depts) and/or soft departmentalised (ie they have ‘Directors’, and ‘Investors’ layers) tend to present ‘ramps, bumpers and traps’ (that’s pinball machine terminology there) against whose numbers, concerns and opinions the earnest product manager can bounce. While these departments and their individuals may record each bounce of a product manager as a success metric for themselves (because they have their own deliverables, metrics and reporting lines which are not about product development), the bounce may represent failure for the product manager. This forces product managers to be rather open in meetings and in their own reporting lines about who or what is enabling or disabling their own hoped-for progress.
IMO, a certain dynamic is also often present in orthodox entities. It is that tech companies (and what I’ve seen of public sector entities) are channelling large revenue flows or large hopes for large revenue flows, and therefore, in addition to the flows of revenue or revenue hopes, it is also channeling large flows of personal or departmental ‘reputation’. People and departments in orthodox entities defend existing reputation and also defend hoped-for future reputation. In such environments, the ‘not-very-much-fun-to-read’ nature of much product manager work sometimes sets up product managers as convenient scapegoats.
Which is the opposite of being a mini-boss, of course.
My environments tended to have a heavy ‘tech support’ and networking bias so the following intricate examples of the above dynamics may be tainted with the flavour of support/infrastructure tech but I think they still evidence my points:
-
Being tasked at director level to write business cases for two expensive-to-develop products and make a recommendation in each case. Time/resources to really investigate the potential customer demand via, say, Sales were, sadly, not possible. To keep a long post short, a key director had envisioned the products and the case for them, and already bullied, er, persuaded the other directors to commit. I first thought the ‘serious’ third-party business cases were required purely to justify the large spend. I eventually intuited that whatever the outcome, the directors could take credit or simply shrug and point to the business cases. This was reputational defence. Funnily enough, I was given another of those to do in the last week of my notice period.
-
I also saw that Sales and/or Support - ie customer-facing staff - often had great product development ideas to explore. The first hurdle would usually be their team/departmental management and the next: Finance. The first was easy to work around: ideate the desired product/service change out of sight of customer-facing middle management or ideate it in a boring way right in front of them (ie require tallies/analysis of support requests and/or product failures). Their managers were - arguably - engaging in terrain defence, resource defence, and possibly reputational defence - by managing ‘obstructively’ during a legitimate hunt for new product and product-improvement leads within the entity.
Finance, on the other hand, were a wonderful hurdle. Although they managed allocation of the large revenue flows that so hypnotised the other individuals and departments, in my experience Finance actually cared about the numbers (as opposed to cared about being credited for the numbers), so their perpetual cynicism (hurdle-building) was benignly-motivated. Because of that, I see Finance as a reliable hurdle that product managers can exercise against until product ideation/development satisfies Finance’s constraints and risk approach.
Unpacking just a little more of the delicacies that can be present in Finance’s role… a lot of product development comes out of new products launched by existing vendors. Often - not always - one’s company is working on a not-fantastic-looking new product because of an invisible aspect to an existing relationship with a vendor. Eg, the influence an existing vendor holds over the T&Cs for existing and future supply contracts. Which might look like: Supplier: “You’ve been a fantastic revenue partner for our disk storage products. We awarded you our very generous ‘Gold’ partner terms and co-marketed you to many customers but you haven’t engaged with our block storage products. Is our relationship at risk? ~cough~”
It’s useful not to have product development fall foul of such forces. Finance are sometimes the only accessible folks who know about the ins and outs of that side of things. One would hope that co-ops might be organisationally resilient against such forces.
Can conclusions relevant for tech co-ops be drawn from my ramblings?
I’d say:
-
Does your co-op house ‘reputational-defense’ dynamics?
-
Does your co-op touch desirable revenue flows? (I think your last gig may be an example of the problem I’m getting at when I highlight this question)
-
If so, do the flows ‘taint’ certain individuals and/or departments?
-
You can ask the same three questions about the entity’s ‘reputation’. Does it have specific ‘owners’? Who has real ownership? Or who has imagined ownership?
-
Is there a middle management? Meaning: people who exist to manage those who do the things the customers directly pay for? This layer sometimes acts as if possessing ownership that they don’t really have.
Turning from ‘how to identify problems’ to ‘how to be a solution’, I found that everyone, from customer to front-line staff were great when I acted in a ‘servant’ role. You wouldn’t expect to have a ‘servant-master’ relationship in a co-op (I expect) but the ‘servant’ part of that meme might be worth trying to sustain in a co-op product manager role. That is, I mean, sustaining as a style, as an approach to the work. So I agree with Rob Redpath on the importance of the ‘servant’ part. Clearly my experience evidences his wider comments.
My point is that heirarchies tend to create fears and vulnerabilities that manifest as invisible - and problematic - dynamics. It’s the heirarchy that creates them; hopefully a co-op tends not to. So then one could ask if other factors might create them in a co-op. The example you provided - of the effect of funding - reminded me of a similar challenge I saw a while back. In that case, a financial gift to each employee damaged cohesion and thence mood (I lack the insight to understand why). But, if one were being interviewed for a co-op product manager role with the explanation that the co-op had just been ‘funded’ then I would worry about cohesion. Equally, if there was a sale that everyone was having to work for and new resources were being sought for, I suspect a cohesion threat might still be present but might be more likely put aside amid the need for everyone to pull together and work to make the sale or deliver on the sale.
I could make other comments but they are icing on the above cake.