Contributing to product workstream 🤝

Knowledge Base
1

As a handy primer you can see the notion pages on how we ship product here at ShapeShift. Link to “shipping pipeline :ferry: " Everything worth building starts with a spec, they can be beefy, or they can be short, but they CANNOT skip on technical due diligence, risks, and metrics for success. Historically, this DAO has struggled with focus, doing the work upfront brings the focus.

  • The process is a looping flexible one with four stages: discovery, definition, in dev, and launch(ed). Anything can be shot back to discovery if we find loose edges or holes to fill.
  • Use cases are essential to the discovery and definition stages.
  • After launch we use data to inform how well these are doing and quarterly we evaluate if a feature needs to be removed, kept, or doubled down on.
    • I’d be remiss if i didn’t say this quarter will be the second time we’ve done this for real, using the learnings to focus the roadmap further into the next shipping period. the last time was titled the portfolio of regrets. Cheeky.

We have a lean cross functional approach and are aiming for a backlog<>in-progress ratio of 3 to 1 on our specs.

That being said, this is a frontier industry with many new ideas and technologies popping up everyday. All ideas are welcome and it’s why we have a canny board. A public repository of half baked thoughts is fine as long as we understand that’s all canny is for the majority of it’s tickets.

That’s what inspired this post: canny is meant to be a place where pre work for specs is completed, the notion is a place for work to get organized and complete, and the community is a wealth of sourcing contributions. Hopefully, this list helps people understand how to be helpful and move things forward.

How to help Product Workstream

  • Bring in users wanting testing experience or new features and curious in sharing their experience specifically their use case. A packed calendar of user interviews is our most important KPI. ( つ ◕_◕ )つ people ( つ ◕_◕ )つ
  • Write at least the opening of specs and be willing steel-person ideas.
    • Specs are living docs that take many sessions of poking holes in and growing into something useable before it’s “shovel-ready” tickets in dev.
    • Crisp documentation & data of why something is: compelling, crucial, or needed.
  • Share a business case or a captivating use case/reason for looking at an ecosystem or feature.
  • “How does it help ShapeShift users or DAO?”
  • Project or integration links - Docs, Dashboards, Implementations, Prototypes, Socials (DDIPS)
  • Bring guests to product office hours ready for diving into specs and get partnership threads going fleshing out ideas collaboratively.

How to NOT help Product Workstream

  • Send videos about what you think product should do, or tweets, or farcasts, or any low effort content asking “when will we do x/y/z” “why are we not like x/y/z”
  • Say “good project” “guys it’s so simple” “this project to the moon” “clearly this is the best x/y/z” “thumbs up” “plus one” but nothing further
    • Gaming upvotes is silly. Bringing your community in to upvote things for traction but not provide anything meaningful about use cases is lame.
  • Drop a link and say something is easy or super low lift.
    • Seriously, do not assume the engineering workload without asking.
  • Argue about implementation details before anything has been spec-ed
  • Drop a laundry list of expectations as a bulleted list without anything meaningful supporting it.

Thresholds, criteria, etc.

As per our product goals, we review features when they hit 15 upvotes. As the board grows, we will adjust this threshold. There is a “goldilocks-zone” of clear use cases, obvious support, and legitimate community requests ( or frustrations, those are totally normal nd we want to know what bugs people! )

Integration requests are currently blocked at the infrastructure layer and will likely stay that way until the fall for 2024 — at worst.

A note on feature requests: they’re just ideas!

Idea’s are fragile by nature, so it’s fine to share as many as you have. Even some requests without upvotes will get evaluated when the timing is right (quarterly reviews etc.)

Unacceptable behavior looks like overreacting to closed requests, or posting on the forum or discord saying our judgment is flawed without reading the roadmap. Please. Don’t get offended if we shut down an idea, it’s just a thought. Get over it and move on, if it’s really worth the resources pursuing it will be kind of obvious.

…that being said

If one is capable of putting in the product work and rallying real cogent use cases, we’re here nurturing that contribution pipeline. That is why we have this guide. :handshake: