Q1C2 '23 Prioritisation

[BenJam]

In December we decided to take a different approach to how we prioritise work at Open Collective. Instead of prioritising individual issues, we asked you to indicate which of the 14 product areas, defined by the product team, we should focus on.

We revealed where we'd spent our time, and where we'd proposed spending our time over the course of 2022. In parallel, we revealed our strategy for 2023-'24, with a focus on balancing our need to grow as a tech platform with our need to mature as an organisation. We agreed that our focus would continue to be hosts that we incubate and are directly involved in, and we committed to co-designing our service with our hosts and the communities they foster.

2023 Cycle 1

In January we started a new cycle with a balance of practical, impactful features and enhancements alongside broader, visionary work on some of our key experiences:

• We made improvements to our core application infrastructure, implemented password-based login which has evaded us for over four years, and added finer-grained control for admins of Collectives hosting Events and Projects.
• We implemented some fixes for users charging VAT/GST and spent time addressing a priority bug regarding Paypal transactions.
• We improved an aspect of our onboarding process, enabling Collectives to be discovered and to find other Collective like them using tags.
• We continued to expand our payment options for contributors, and build an MVP to help hosts who process large purchase-order-based transactions on behalf of their member projects.
• We reviewed our approach to user support , highlighting some priorities to address in future cycles, both within the platform and the teams supporting those processes.

Finally, we explored a future vision for how users might interact with Open Collective in two modes, as a supporter or as a worker. This experience is tied intimately with our onboarding experience and how we present and differentiate entities on our platform. Our work in this area was expansive rather than focused. If I'm brutally honest, I think we still lack answers to some of the key problems identified with our profiles or the next steps for onboarding improvements that were first raised in October '21.

2023 Cycle 2

Onboarding, Precence and 'Workplace'

As ever, there are many things vying for our attention. Given the time we have dedicated to exploring the trifecta of our onboarding, profile differentiation, and onboarding processes, combined with our experience of going back to the drawing board from the work we did in 2021 I think it is best to continue working in these three areas. Specifically we should:

• continue the work to establish a workplace-focussed experience on Open Collective Establishing a "workspace" on the platform #6385
• begin work to differentiate entities on the platform Establish a unique collective profile experience #6415
• align users to a golden path of creating a user account, creating a collective then picking a host Improve the onboarding flow for a user creating a collective and selecting a fiscal host #6440 - Loom demo: https://www.loom.com/share/0ca0a9328b7a4e3c8c7e18ed3329ed37

Support and Operations

With the support team having recently re-org'd itself into a more effective configuration I think it may be time to pick up on addressing some of the top-of-funnel issues identified, implementing search if GitBooks will allow and automatically adding triage information to tickets on FreshDesk now that we're paying for a pro account.

Discovery

Having released our new discover experience at the end of 2022 we have been gathering insights and feedback on what we got right, and what could be improved, but we're not confident we have a set of requirements for a follow up cycle. We'll work to establish the next steps this cycle while making a small, impactful change to how collectives can communicate the location(s) they work in with #6281

Payments

In late 2022 we (okay, @kewitz) looked at improving our anti-fraud measures. With changes to our support team and the invasion in Ukraine continuing I think it's important to ensure that we continue to re-disk and increase the efficiency of our payment processes. We should expand the current warnings to:

• highlight when a payee does not match a payout methods details (name, address).
• highlight when a payment is abnormally high for the individual or collective from which they are requesting a payment.

Core

The engineering team have a few core concerns that they would like to address this cycle:

• Continuing to address problems with how the platform records/handles tax, specifically the problems we are having with GST in NZ.
• Continuing to improve our user security, adding Yuibikey support as a second two-factor authentication method
• Improving our tools for hosts and their accounting, namely
  • providing options to include/exclude data in transaction exports
  • making the limits and filters of our CSV exports more obvious

Contributing to this discussion

The projects selected above have been done so on the basis of strategic alignment, impact, urgency and readiness for development. As I wrote last month we are moving toward a process that allows us to build and communicate a vision to the team, and to work more purposefully toward than vision while balancing the more immediate needs of our hosts and our users.

My promise to you was to provide a space to highlight specific issues within a process that treats individual issues and feedback as an input, rather than a conclusion. This is that space.

If you feel that the above does not fit your expectations, that we've missed something vital or that we are moving in the wrong direction tell us. This is, as ever, a discussion.

Thanks

[alanna]

This is awesome, thanks for taking time to write it up. I love how it's shifting to a more thoughtful process that can tackle big picture problems, not just looking at issues in isolation.

I do still have a question about what to do with small pain points that would be great to get fixed or relatively small concrete things we need for compliance/ops. Where do we put such things and how can they still get prioritised when the focus is on big picture product areas?

Examples for OCF: #6418, #6241, #6102, #6093, #5817, #5747, #3433, #6427, #4894, #5426 - and a whole category that will never come up in big-picture product prioritisation because it's OCF-specific, updates to our application form: #6297, #5845, #5758, #4115.

[shannondwray]

@poohlaga Interesting the examples of OCF-related things that need fixing, they all seem ops related. Have we been successful in getting the OCF ops team to come to our Support/Ops meetings yet? This could be where these things are watched @alanna, Priortised by our cross host ops/support team and then pushed to product/engineering to get scoped/built

[iamronen]

@alanna I am lifting my head up from focused work on what I believe will be an in depth response to your inquiry. I do want to responding briefly here.

• Yes, we have shifted to a more directed and thoughtful process and I am glad we have arrived. This feels almost celebratory to me :)
• Some clear small asks are making it into prioritization (mostly due to @BenJam and @znarf identifying and surfacing them).
• Some of the issues you've pointed to (I have only browsed them so far) will, I believe, transform into better asks.
• Some of the issues will naturally find a place on the strategic progress we are starting on (I acknowledge you can't see this yet, I am hoping this will change during the coming cycle). I think they will be solved better when they are addressed in context and not as separate things.

I will respond (ASAP) directly to some of the issues you've surfaced to demonstrate what I mean.

[alanna]

Yes I trust that the new process will be much better in the long run. I guess I'm just feeling the pressure on scalability in the short term as we're struggling to keep up on the ops side and we need the tech to support us with that. There's always a balance between "passable and faster" vs "better and slower".