Aadil Mamujee

You don’t need much process when you’re a small company (<10 people). Everyone knows everyone and everyone knows what everyone else is working on. This is a magical place where the best ideas usually win, and people operate in a high context and collaborative environment. This phase works best when people are highly autonomous and need very few approvals to get work done.

As a company scales, particularly beyond 50 people, more process is required to ensure the people who need to do the work understand the context. This can lend itself to “everyone needs to be in every meeting,” which is inefficient and promotes a hierarchical working culture. Cultures, where success accrues to the people with the most context/knowledge, create lower productivity and a more political environment. It’s easy to fall into this trap without intentionality behind the processes and rituals at your company. Each company is going to have a different culture and operating model. The most important thing is that the organization buys into common rituals. If you force the team to follow rituals, it never really works and leads to frustration and resentment.

Here is a product operating system I’ve seen work well over the last decade. It represents the full lifecycle of a “long sprint”,  typically 1-3 months of execution:

1. Start by establishing company goals
2. Break down goals into focus areas and assign these to cross-functional teams
3. Prioritize projects within focus areas
4. Build and launch projects
5. Follow a simple system to share information internally
6. Complete a retrospective

Company Goals

It’s helpful to have a consistent “mission” that is long-term and consistent and goals that are medium-term and more fluid. The cadence at which you revisit goals depends on where your company and industry is in its lifecycle. More dynamic industries and earlier-stage companies need to rethink and adjust goals more frequently. The cost of changing direction is getting teams to buy into the new goals and internalize these goals when executing on a day-to-day basis.

When approaching goals/planning for the first time, involving people at different levels to brainstorm ideas (with the right guardrails) is helpful. This is mostly an exercise of teambuilding and occasionally results in out of the box, excellent ideas. It’s the leadership team’s job to curate and prioritize these ideas, and it’s fine for this to be top-down. Periodically adjusting goals should be light weight unless there are significant changes in the market, customers or company. Once focus areas and individual projects are prioritized, there needs to be allocation of focus areas & projects to different teams. This is where load balancing needs to be considered across the company and where team design is essential. Ideally, focus areas are non-overlapping across teams so teams can work fairly autonomously.

Goals can be ship goals, growth goals, or performance goals—it all depends on your stage. You just need to use your judgment to figure out how metricsy you want to make these goals.

Focus Areas

Each focus area should have a clear and nonoverlapping mandate with dedicated cross-functional teams when possible. Focus areas can be organized by product surfaces, metric goals (e.g. growth, monetization), stage of funnel (onboarding, engagement) – it really depends on the product and business. Like the company, the focus area should have a clear mission and set of goals. I prefer when there are 1-3 things that cannot fail that ideally roll up to overall company goals. Everything else can live in a prioritized list, but the team and the company understand these are a step function less important than the top 1-3 things.

For each focus area, I like to create a “workspace” which has all the important information at a glance – why this focus area? who’s on the team? what are you building? what are the priorities? This helps the team stay organized and also helps new people onboard into the work more easily.

Prioritization

Once the focus areas know their priorities, you can break these down into Now/Next/Later groups, which lets anyone at the company and the team understand the priorities at a glance. This should be a fairly high-level view into the projects, and specific details of executing on the “Now” can be handled in a engineering/product/design system like Linear/Jira, which is at a much more precise level of detail.

Prioritization/roadmaps must be “public by default,” at the right level of detail, and free of jargon so the rest of the organization can understand what the team is doing without needing to pull the information from the team.

It’s also important to re-iterate the projects/work that cannot be dropped and are the top priorities in prioritization. It’s easy to get lost in the noise of execution, so consitently drawing attention to top-priority projects is essential to get right at all levels of the organization.

Product Development

Every team will have different norms for building features, depending on its composition and the nature of the work. There are a few fairly ubiquitous rituals and I’ll summarize them here:

• PRDs/RFCs/One Pagers: You need a clear and concise way of communicating the problem, the proposed solution, and the risks. This should be a short document, with a consistent format coupled with a lightweight process to gather feedback, necessary approvals and share the output with team members who need to be informed.
• Burndown Lists: A burndown list is a set of tasks (with assignees) that must be completed before a feature can be launched. This is a dynamic list that is reprioritized continuously before a feature goes live. It provides clarity to everyone involved with the launch and allows for scope and timeline tradeoffs clearly.
• Customer Engagement: At both consumer and enterprise companies, you need a clear plan to get the product in customers’ hands and have quick cycles for feedback – this builds trust and loyalty. Customers need to understand the feature, be excited to use it, and feel empowered to share feedback. Many crypto consumer companies do this very well with platforms like Twitter, and the best enterprise companies have clear and often real-time communication channels with their customers.

Information Sharing

Internal information-sharing processes can cause a lot of frustration and friction. Synchronous updates with many participants can be a soul-sucking experience, especially if what others are working on is not relevant to you. However, sharing what people/teams are doing is helpful, especially if you want to reprioritize or resolve blockers.

For people and project updates, I like setting weekly intentions (what you plan to do) and following up with weekly snippets (what you did). I suggest that people updates happen within the “focus areas” and project updates happen in a more global forum to reduce signal from noise (global people updates break at around 20-30 people) and make sure the right people read the updates.

For both people and project of updates, I suggest an async forum (e.g., a Slack Channel) that is public by default and limited to the top 3 things for the project. Questions and discussions can happen asynchronously, and if there is misalignment, the right group of people can jump on a synchronous meeting.

Retrospectives

I’m a fan of lightweight (blameless) retrospectives after a project is finished. This does not have to be a drawn-out ordeal, but it can be a quick 30-60 min discussion about 1) what went well, 2) what could have gone better, and 3) what we will change going forward. I like having a consistent template (linked a Notion one I like that you can duplicate) that lets anyone on the team add items and vote them up. I also suggest a dedicated channel to share the top 3 learnings/changes from the retro, as this allows the entire company to learn from each other.

---

This is a high level overview of a product operating system that can work, and is not meant to be prescriptive. Companies of different stages, cultures, and product types may be able to get ideas and use elements of this way of working. Most importantly, you should operate with intention behind your rituals and not fall into sloppy working process because you failed to periodically evaluate if your operating system still applies to your company.