Grants and product development processes

I’m not sure yet that hiring a Product Manager to produce a Dsp Specifications Document is going to result in much more than an inert piece of paper. It seems we need to have a convo about agile vs waterfall product development and why the industry is moving toward agile.

If the Product Manager role was doing what a Scrum Product Owner does, I’d feel confident that we’d have something genuinely useful. A Product Owner works with workers and stakeholders to clarify and prioritize product requirements as user stories in a work backlog. The team starts working right away to produce useful improvements we can get feedback on and iterate off of.

Can grants only be won in exchange for us conforming to waterfall-style planning and mode of work? But what if that mode of work and planning just doesn’t work? Agile was a response to waterfall-planning’s problems, so it seems in exchange for funding, we’d be committing to many of waterfall-planning’s problems.

Lastly, the Product Owner would be trying to have convos with stakeholders, members, and customers at Resonate to clarify requirements for what we want. With capacity here so low, who is going to be available for these convos? And will those who aren’t available accept the vision and priorities set by the Product Owner/Manager without their input?

1 Like

Let’s be honest: how many times at Resonate have we made a detailed plan, followed it, and delivered it on time as planned? …it is certainly not the norm here.

On what grounds do we think the DSP Plan will be different? Especially since the proposed Product Manager will possibly leave right after handing off the Plan?

1 Like

I would also like to use that thread to encourage having a topic that explains exactly what the product manager/owner/facilitator job will be, how it will relate to the community (Monthly calls? How will we reach to the product manager? What will be their responsability to us? Will their presence be frequent within this forum/community, on the mattermost etc. so many questions !), what is expected from them in relation to the platform (do they set up/organize/prepare/steward the monthly/bimonthly calls? Do they take notes of decisions voted on or proposed by the community? Do they initiate those? Are they entirely tied to the MVP DSP plan or have some margin of adjustment?), what will they pragmatically do (UI Design/Figma? UX design based on user stories? Managing the maintainers? Will they mostly manage employed workers or volunteers? Will they be working towards an “overarching document” for grant aproval or towards ending subsets of little goals to improve the current experience on the platform? What will a day in their life at Resonate look like?).

There are all manners of questions I have regarding what that means for us and especially, how the interaction between the various unofficial/official-ish entities at Resonate (the board, the finance work group, the maintainers, the people-on-the-forum, the people-on-the-mattermost, the dismantling-white-supremacy discussion group) will be handled with that one critical role in the middle and how accountable they’ll be to the way these entities are articulated together or not (is it something they should care about? Not care about?).

As I said, I’m more confused than anything by that role, I understand it in the absolute, but I have trouble making sense of it in our specific context.

1 Like

@LLK I pitched some anticipated responsibilities of the role here: Defining product manager role + Product management routines

1 Like

It is absolutely the type of document I would like on the forum but like, making sure everyone’s on board with that definition and also, making sure it’s clear who does the work that this product manager is organizing !

I feel like I’m missing some context for this conversation, but am interested in contributing. Is there another thread I should read to get up to speed? Or are you looking at grant applications and seeing some language that hints at waterfall-style expectations?

Without a consistent development team, I would argue that even Agile methods may be a bit of a stretch and that we’re really better served by a Kanban approach. Regardless of how the development work is managed, it makes sense to have an over-arching roadmap. (Agile actually supports roadmap planning, but most people tend to overlook that side and focus on setting up scrums…but I digress.)


Useful vid, but another reminder that it will be up to us (and the product manager) to clarify what exactly the role needs to do at resonate.


I agree with you and emphasize a kanban approach in the Kielest framework. I see scrum as worth aspiring to (and it could fit within Kielest) but it seems to require more capacity than we currently have. Based on the results of the Premises Poll, most folks don’t think we can commit to sprints – at least not as a practice across all working groups.


For context, Resonate is currently in conversation with Justifay, a Spanish co-op with very similar goals as us, to create a collective plan forward for both of us, so that we can use the same code essentially. They’re in the process of applying to grants, and this is where that conversation is stemming from.

I think that if you see Resonate as a co-op that’s trying to build a music streaming (distribution?) platform, the question should really be framed as:

What hire should be the first (in this iteration) person to be hired by this co-op?

My answer to that is that it should be someone who does the administrative work of trying to build consensus around a path forward, making sure meetings happen, people are followed up with, decisions and actions are documented, and generally make sure that things are easy to get members and volunteer workers involved in the process of decision making as well as having everything they need to get stuff done.

Right now I’m seeing that there is no capacity to do that kind of work from a volunteer, so it sounds like we need to pay for someone to do it.

I’m also not sure that getting hung up on specific role names is important. I have reservations around adapting processes from the (largely not so great) tech industry to do our work around. That sentiment is not much more thought through than that sentence. If we’re trying to be a collective that ultimately will shirk off hierarchy and be a co-op (that realistically will be very volunteer based for the foreseeable future), I think we have to think through other ways of organizing ourselves. Luckily there’s already conversations happening around that!

I’m also observing that there’s two groups of people having seemingly conversations next to each other. One group is in the calls with Justifay, trying to come to an agreement with them, and the other group is not in those calls (though I think they’d be welcome to attend, but that might not have been made clear or explicit) and is feeling frustrated that there’s not a lot of insight into this process.

On the topic of Kielest, we should be (in agile spirit!) put it to the test, imo. And then the conversation becomes “under Kielest, who would get paid?”


Great summary, @psi

I’d go to the Justifay calls but I haven’t been free at those times. Then I’ve shared ideas and feedback here when I am available. That’s the best I can do in that area! :frowning_face:


In terms of borrowing from the industry, I think a lot of folks have bad experience due to how many “fake” agile/scrum teams are out there. Names and branding but little understanding of the intent, and low support for the self-management that Scrum triple-underlines as being essential.

I’m talked to folks who say their company does scrum or agile – then they describe the company and almost nothing is happening in the way Scrum intends. Everyone divided into hard roles, micromanagement, no cross-functional teams, no scrum masters, little trust or support for self-management, no transparency, no coherent backlog, teams being pestered by randomly-appearing tasks during “sprints” that are treated as a neverending gauntlet of rushed deadlines.

Tragic, honestly. And from Scrum’s perspective, a huge waste in happiness, productivity, and creativity. I’m still new to studying and learning this stuff but it does seem there is a chasm between Scrum and “Scrum”.

1 Like

Echoing that, I’ve been made aware I could attend justify calls I think 2 weeks ago or so, so that’s two meetings I could have joined, but they were not at a suitable day/time for me to attend so I’ve voiced my questions and concerns elsewhere, which does make it seem like two conversations happening past eachother but I guess that’s because the thing only happens where it happens and that the…

“person who does the administrative work of trying to build consensus around a path forward, making sure meetings happen, people are followed up with, decisions and actions are documented, and generally make sure that things are easy to get members and volunteer workers involved in the process of decision making as well as having everything they need to get stuff done.”

… isn’t there yet ! So you either need to be exactly at the place and time where decisions are taken, or speaking through writing and posts on the forum or mattermost gets mostly ignored or just, you know, seen but not acted upon and taken into account.

I agree also about the statement that mimicking industry standards isn’t for us but yeah, as @Hakanto said, and also as has been evoked in this topic Are co-operatives democracies? 6 components of democratization - #11 by Nick_M there’s such a huge delta between “the model of work organization” companies pretend to use, and how they trully function in reality that it’s really hard to treat the former as the latter.

Anyway, I do plan to attend the next Justifay meeting just to get a sense of what’s being discussed there and what are the concerns and strategies expressed on both side (and I mean, get a sense of it directly instead of through short logs of what’s been said).

I do note though that the Justifay meetings are not indicated on the Resonate Agenda which is what I use for my reminders of meetings so this doesn’t help have a clear picture of when to join either (I mixed up two meetings 2 weeks ago mistaking one for the other).


Since I’m the representative from @maintainers for the Justifay collaboration, I want to try to get to the bottom of this… There wasn’t any dissent on this topic in the Dev Standup Meeting on September 14, 2022 where it was decided that folks interested in being involved enough with Resonate to join the Mattermost should be able to join Justifay meetings (hence why the link is posted in the Justifay Mattermost channel when they’re happening). You attended that meeting @LLK, so it sounds like you’ve changed your mind since then? We should talk about it! As these talks continue (and gain momentum), I’m all for checking in and making changes in the efforts of transparency and including the community in these discussions. (If you’re reading this and are not in the Resonate Mattermost and would like to be, you’re invited to join: Using Mattermost - Guides - Resonate Community Forum)

I’d like to echo @remst8’s sentiment here. The current bottlenecks surrounding getting this work done in my mind are the amount of hours current dev contributors have to contribute, not how organized the work is. Using the Product Backlog has been huge for this!

To revisit @jeremy’s proposal:

(I’d like to note that when I look at this proposal, it’s incredible how many of the things we’ve already adopted. Makes me very happy!) Take a look at the budget on Slide 16 in particular. A common goal between our cooperatives is to produce an open-source Accounting Engine, a public good, which both co-ops (and others! Yay open source!) could use to report back to licensing agencies, and perform all the legal functions necessary to fulfill the requirements of being a professional DSP. I’m all for emphasizing volunteer involvement, and the more volunteers we have rotating in and out and taking meetings when others’ schedules are busy and the more agile we become as an organization the better! I also suspect that acknowledging that we need both, volunteer and paid labor, is necessary for the task at hand. Expecting volunteer devs to contribute tech worth that many thousands of euros strikes me as unrealistic.

I also think some of this is the culmination of a desire to improve upon how we worked together in the first phase with Justifay - the agreement was that there would be a set of tech deliverables, and ensuring both parties had the same expectations regarding those deliverables, and producing those with limited dev time/resources proved tricky (it was achieved! but it was tricky!) - hence why a deliverables/future steps report from a Product Manager would be a good thing to expect as a result of this new phase of work. We cannot apply for larger grants if we don’t have a document stating exactly what we’re using the money for, how, and why.


Thank you @psi and @piper for providing helpful context, and @Hakanto for adding me to the Justifay channel on Mattermost so I can see more history.

This absolutely makes sense–and that expectation may appear to presume that waterfall development methods will be used, but I think we can develop a robust plan without going down that road.


It should also maybe be mentionned (maybe it was somewhere?) that the amount being discussed for Phase 2 is roughly 30k€ so it’s hardly enough to do all that’s envisionned currently anyway, so the question at hand about the deliverable is kinda “what is a realistic and needed deliverable that can be actually finished when the 30k envelopp runs dry so that we don’t have a half finished job that volunteers need to then tackle because the paid personnel left”.

This reasoning indeed doesn’t leave much place to consider an actual dev plan where the deliverable would be the accounting engine itself, not even talking about a “professional DSP” etc. (but maybe I’m wrong about this, it just seems like not a lot of money to me to acheive this), so indeed, in light of 30k being the budget, and the need to make that budget make sense in a global strategy, it seems like it most makes sense in a strategy where the endgame is more grant money.

At that point the success of the collab with Justifay will in part rely on their capacity to raise more grant fundings and on our part, on our capacity to be legitimizing them through what Resonate has already acheived so that the joint effort appears as something worth investing in.

I think all of this makes sense, if that’s what we’re after. I can’t tell if it will work or create more tension / stress on the current workers etc. I also can’t tell about the success of the hiring process because so much will probably depend on who we hire, but as usual when there’s money, partnerships, and grants involved, there’s tons of uncertainty.

Whatever happens I’ll try to help any way I can if I can at all ! I feel like it will just be good to be mindful of how the situation developp, make sure workers are happy with how the situation evolves (both paid and volunteers), that they can do their job, feel respected and have agency, and also that they’re mindful of the people in this space who don’t participate in dev work, and especially (something we’re terrible at) ensuring that there’s full transparency on the whole process !

These are my thoughts so far. Not sure they’re useful or anything, there’s nothing in there I haven’t kind of already said. But it makes sense, no matter the way we decide to work in the near future, we’ll need to watch out for the same things, just under different contexts.