As a handy primer you can see the notion pages on how we ship product here at ShapeShift now. Link to “shipping pipeline ⛴️ ” ( https://www.notion.so/shapeshift/Product-Workstream-16fcd5de93334a389adc656a8bedb570?pvs=4#dbb7f35abc014e47beb7b275c1518db8 ) 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.
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 lie 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 with 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.