🌿 Product dev culture

• Goals, goals, goals. Everyone owns what they’re building and should understand the “why” behind their projects. The user problem and success criteria are clear at all times to inform down stream decisions.
• Get product out to users ASAP. You can’t learn by over-thinking something in a corner— you learn by getting features in user hands. We ship a lot to learn faster, and everyone is usually involved in 2-4 experiments at any given time.
• MVP mentality. Keep things simple and focus energy on the most important parts of the feature. If something is redundant or not required for the goal, trim it.
• ROI-focused. Upside vs effort is always important for evaluating priorities. If it’s quick, just do it. If it’s a bigger lift, we should be clear on the upside and and our appetite for scope.
• Data-driven. We let the data speak. Our team runs experiments to evaluate user impact and anyone can run experiments or use data to make a case.
• Human-centered. We balance data with qualitative insights. Monitor community feedback and conduct user research for a fuller picture. Collaborate with User Happiness to quickly address user concerns.
• Directionally correct. Speed and building toward a good direction is much more important than perfection or being “right.” Prioritize energy on the most critical details and assume we’ll iterate on the less urgent details.

📐 Scope norms

Time is our team’s biggest constraint but use it as an advantage— time constraints are good to force us to aggressively prioritize, keep things simpler, and cause us to think creatively.

Whenever we’re evaluating the ROI of a project, we should call out the appetite we have for the project scope and then re-evaluate as needed. For reference, historically we’ve gotten many quick swings out within one calendar day and big swings out within 2-3 calendar weeks.

Below is a more detailed breakdown of how we think about scope from the perspective of either a designer or an engineer.

We aim to have a rough scope for every project that starts, split by design and eng effort. This allows us to evaluate our appetite for the project.

• Design effort: we should have an initial concrete scope for the design exploration with a clear date for the project team to regroup. it’s normal for design to surface new angles or challenges we weren’t aware of, so it’ll be natural for the team to dynamically adjust the design scope with new information.
• Eng effort: we won’t have detailed scope until we finalize the design, but we should always a general sense of whether this is likely super quick vs days vs weeks.

After we finalize the design, we will revisit the expected eng scope, which can surface more opportunities to further simplify the design as needed.