This is a bit of a tangent but I do want to clarify for the record.
The reference for salaries used here for the Finance Team is from Q2. There are some major differences between that budget, Q3 and Q4, and now the Q1 proposal.
Q2 you can see I have a time commitment of 50%, so a $120k “salary” in this context means $60k per year. Also important to note that only $12k of that per quarter was USDC and the rest POOL.
The new budget request process says that we will not outline our individual compensation schedules. It’s about deliverables not salaries, like a grant. Though this may not be fully the case in current practice if we are being honest. That’s even further tangential and can be discussed in another topic…
Thanks everyone for the feedback so far. Pooltime hears you. I hope more people will share their opinions.
I’d also like to see this proposal split into Dec work and marketing. I think we need both but it’s hard to see what’s what.
For the marketing side of this proposal, I see issues in the approach. We’ve been doing most of the items mentioned for the past year or two and that route can be effective if the product is 1. Aligned 2. Working and 3. Easy to find/use.
Marketing the product launch with no incentives set us up for failure. No partnerships were secured for launch.
The product is currently broken and the headline prize is a footnote in the obituaries. V3 had the bill, v4 had 1 million in subsidy, v5 launched with?
Marketing teams can’t use the Twitter…and now our app is on a different webpage (cabana)…that made us way harder to find and we are essentially starting over in the marketing world…PoolTogether.com doesn’t even route you to v5…it gives you options to guess your path to find our product for 1.7million USD.
Those are my marketing comments.
The pooltime app should be separated and id vote yes on that. It’s great to see it spawn from the community.
The community management should be separated as that is needed and well done somfar as well. But the price is difficult to understand because of the mix.
Thanks for your review. Any feedback helps us to improve. I feel for some parts it’s important to differentiate between the product side (which is out of our control) and the marketing side (which we want to double down).
Launching with incentives would’ve been good - but the tech for that was not ready at the time. We have been involved in many of the ongoing partnership conversations and initiated partnerships with Portals, Superfluid, and ethOS. For Q1 we have a few more under the belt and have cross-marketing & content planned with some of the most famous wallets.
I’m as unpleased about the roadblocks as you, but this is something that isn’t in Pooltime’s hands. We’ve done our outmost to support the betas, the launch, and react to roadblocks in development. We’re confident that in Q1 the air is clear to focus on the improvements V5 brings.
This is infact not true. I’m managing the official @PoolTogether_ handle on Twitter on behalf of PoolTogether Inc. The handle has a very strict “voice” (see here. Content that fits under that has always been publicized, reshared, or reacted to.
We want to get darby in, so we can closely collaborate on getting more helpful and educational content over the finish line.
Clicking on “Use PoolTogether” on pooltogether.com leads you to a page with the available interfaces: PoolTogether.
Working closely together with underthesea and Lonser over the previous months has been extremely helpful. It’s very hard to execute the things we do alone. Code and app need testing, content needs second opinions and cross-readers, etc.
We initially teamed up to improve each other’s work for the community. Being alone on a “community team” feels like a meme - the Pooltime team has been an approach to professionalize and grow from our collective learnings.
Are you fixed on your opinion or would it help to see a clearer allocation of funds like how much goes into dev work, community building, marketing, R&D, etc. on an improved version of this PTBR?
I want to preface this saying that I value the work that the Pooltime team has done and I think we have very high quality and competent community management that has been and will continue to be a vital aid to the growth and reach of PoolTogether. I also am excited to see @poptones added to the team to amplify PoolTogether’s voice in socials and partnerships.
I think the endeavors of the team align with the need for growth and community safety at this time; however, I have some reservations relating to the overlap of community management and development of the Pooltime application. Although the close relationship has been expressed as helpful and efficient, the goals and deliverables do not significantly overlap between the two. Although I value both the app and the community management, I would much rather see two teams (Pooltime Team and Community Team) with two separate PTBRs to clearly distinguish the deliverables and cost of both.
@Tjark 's has expressed the following with regards to having a community team:
Being alone on a “community team” feels like a meme
I understand this does not feel right (even though @Tjark often does the work of an entire team by himself). However, it’s my understanding that if the community team were separate from Pooltime, @poptones would be part of this team, right? This uncertainty shows the confusion of roles that is happening on the Pooltime team and lack of clarity for where the resources are going. Is Darby being brought on for socials, community building, and community partnerships or is she being brought on for Pooltime integration partnerships and application marketing? If the answer is both, I still believe the community team is a better fit and that the two teams can collaborate when there is overlap.
Separation of user applications and protocol growth is a positive tactic that will leave room for the development of more user experiences in the future from 3rd parties looking to build on top of PoolTogether. If we intertwine our protocol’s voice with the voice of one application, we suffer the consequences of solidifying our product as an app instead of a protocol.