Product manager roles at co-ops

Hey all, I’m doing some research at the moment about the role of product managers within co-operatives. In general, I’m coming up against the following issues:

  • ‘Product manager’ is a loosely-defined role that differs across organisations
  • Existing guidance tends to focus very much on navigating hierarchical structures
  • I can’t seem to find many examples of product managers in co-ops other than Co-op Digital

Specifically, I’m looking to help frame the job role of a product manager within a tech co-op, and so am interested in previous examples / prior art.

Can you point me in the right direction? Even if it’s just someone or an organisations who may know more? :slight_smile:


I don’t know if those problems are any different outside the co-op world. I think product mgmt is a problematic role as it can be inordinately top-down, it’s like a mini boss. I’d hope a co-op would reimagine it to be more emergent or replace it with multiple collaborative roles. But ideally, they can provide value to a production team if they understand at least one aspect of production in depth, bring business/market knowledge to the team, and can help structure operations or production process.

Thanks @colombene, you’re right to raise the ‘mini boss’ issue, which is part of the reason I wanted to bring this up. Even in hierarchical capitalist orgs, there’s a recognition that product managers shouldn’t be like that.*

So I’m keen to see what the role description looks like for product managers in co-ops (and non-coercive orgs in general, I guess).

*For example, in his book Inspired, Silicon Valley guru Marty Cagan says "To be absolutely clear, the product manager is not the boss of anyone on the product team.

I’ve got no idea Doug, but I think at Sheffield Hallam Business School, Rory Ridley-Duff probably knows of studies at that sort of level - have you met him? Worth asking:

1 Like

Looks like an interesting guy! If anyone knows him and can make an introduction, I’d appreciate it. Always better than a cold, easily-ignored email… :slight_smile:


So, I’m a product manager / product owner in a co-op! I also used to be a PO (there is a difference, but it’s lost in the loose definition of the roles that you mentioned) in a non-co-op.

I’m very happy to have a chat or answer any specific questions. In general, I don’t think that there’s actually that much of a difference in the theory of the role, but quite a difference in the practice of the role.

This observation was interesting to me:

Even in hierarchical capitalist orgs, there’s a recognition that product managers shouldn’t be like that.*

because it’s entirely true, and I’ve heard of organisations right across the spectrum, from PMs just being bosses, through to genuine recognition of the value of servant leadership. None of the literature (that I’ve come across, anyway) has examples based in co-ops, but lots of the ideals and best practice sound very familiar.

For my part, I see my job as serving the dev team - helping make sure that they can focus on the task at hand while I’m going off working out what we’re doing next, dealing with stakeholder messiness and all that.

What I don’t have, and I suspect many PMs in hierarchical orgs do, is an internal battle to fight around wider business metrics and/or irrelevant people’s opinions. I only have to care about what your niece thinks we should do if your niece is either a domain expert or a user of something that we’re making. I’m not solely accountable for getting projects done, I don’t look bad if we’re late (unless I made us late!), and I don’t have to prioritise features based on what the CFO wants to talk about on the earnings call; as long as we’re getting paid, the features follow stakeholder agreement.

Hope that’s useful, and let me know if you’d like to chat further.

Thanks Rob! That’s really useful context :+1:

(full disclosure: I recently resigned as product manager for an open source org that got $millions of funding which changed it for the worse)

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. :slight_smile:

  • 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.


Wow, Lee, thanks for that (and welcome to the CoTech Community!) :clap:

Still digesting much of that, and it meshes somewhat with my experience, but helps crystallise it by explaining better than I ever could. I particularly like your description of the role of reputation within ‘orthodox entities’.

Much to think about, and I might come back later with some questions. But for now, thank you! :+1:

Thank you for you comments Doug. I have just edited it to try to make the pragmatic aspects stand out a bit more.