This is a part of the User-Driven Programming Series.
Building an effective system to produce user-driven programming means that we’re creating a platform not a product. Let’s define terms here for a moment.
We’re going to use the word product to refer to a particular program, series, or project. It is the end result that will face the audience. This might be a speaker series, a study group, a concert, or a running club, for example.
By platform, we’re talking about the toolset to implement a wide variety of projects. The system to create, implement, and evaluate programming consistently.
In a user-driven programming model, the institution is the platform to create the programs, while the members, congregants, or users create the products.
Imagine your organization as Etsy, rather than the artist, you are the grocery store, rather than the bread. Our role, in this analogy, is not to make the video on our own, but to be Youtube, hosting and providing the tools to create that video.
Because we’re creating a platform, not a product, we have to understand our roles.
Without this clarity, there is confusion as to what everyone is supposed to do.
The role of staff is to facilitate lay programs.
The role of lay leaders is to own and run the programs.
Without this expectation, then the system you’ve built will not function smoothly. In most organizations, the various programming departments are the product themselves. The rabbi might teach classes, for example, without thinking about how those classes should be part of a holistic system. Lay leaders might end up serving advisory roles instead of pulling up their sleeves and being a part of the solution.
Now, of course, there is some complexity here. The world is not made of up neatly drawn lines. So it is important to understand how these roles are not as simple as they appear.
Some programs are significant to staff members, who are willing to create the products on their own. This is not bad on its own, but staff-driven programming should be in balance with user-driven programming. For example, I teach a weekly Talmud class. While my students are certainly engaged, this program is driven primarily by me. On the other hand, there are programs driven by members, like the parashah study group mentioned in the post about expressed needs.
This balance should be maintained so that the system we’re creating empowers leaders. In fact, staff-driven programs might want to follow the same implementation strategies as laypeople, to maintain the platform quality of the system.
Ultimately, in creating a user-driven model and building a platform, we’re creating a new culture around who is responsible for what elements of programming.
By focusing on a platform framework, we can always step back and see the broader strategy at play.
Have a question on how to implement this? Want me to help you set it up? I’m available for consulting and I’d be happy to work something out for you and/or your organization! Reach out!
[…] we understand that our model is a platform and not the product, it also means that on some level, the job of the staff is to try and say yes as often as possible. […]