Product Development: III. Cycles

Small startups and teams die when they try to emulate large companies. They need to be agile and have momentum. Startups are a marathon, just like the career of any great sportsperson. They kept going for years but with continuous periods of high-intensity work.

To run fast product development cycles, we need an engine where the next item on the roadmap is shaped and ready to be developed /shipped weeks before the engineering team, releases should be continuous, and GTM should always be abreast with new features coming down the pipe.

Once the discovery/validation/prototyping done by product/design is ahead, you end up with an efficient engine (with clarity on what to build) that can churn out features at a fast pace.

These are the main components of the engine:

1. Discovery/Ideation¶

The product development process starts with the identification of a customer need. This can come from many channels, including but not limited to:

1. customer discovery call
2. qual/quant analysis
3. product/engineering insight
4. competitive landscape
5. sales/support/marketing feedback

Product should be engaged on identification of a new need.

The product lead has to solidify the lead, qualify it with qual/quant data and map it to the existing product roadmap.

Product might run iterations with design and engineering to scope out early versions of this idea. They may go as far as building a scrappy prototype without much approval if there is a strong conviction and a nod from the founding team.

Once there is a strong conviction around a feature, the product lead should work with GTM to develop the main artifact, which has the messaging for the feature. This could be a landing page, a video storyboard, a demo script or a memo.

Spikes / Technical De-risking¶

Sometimes, there is technical uncertainty around a feature. In such cases, the product lead should work with engineering to spike on the technical aspects. The spike should be part of the regular cycle to get to clarity. Once there is clarity, the feature will be scoped out, and the above steps with GTM will be completed before going into development.

PRD¶

Read RIP PRD for more details. Linear provides an excellent tool for hosting product/eng context for every project/feature.

2. Planning¶

The world is moving too fast to plan across quarters and years. It is ideal for working with six to eight-week cycles for most things purely software. Each cycle has a clear Big Picture (B), Priorities (P) and Measures (M). Every week, the team works towards the BPM. The BPM can be broken down from company level to individual teams.

3. Development¶

Humans tend to fill up any amount of space/time they get. Weekly sprints keep the team focused. Each week starts with a planning meeting to align the goals for the week and allocations. The team meets daily to track progress. See meetings for more details.

The product/eng lead should not try to create atomic tickets on the Kanban board. Instead, everyone should focus on a customer-centric (product) ticket. Engineers should be able to pick up the ticket and add any/all subtasks they want to add to break down the ticket and work on it. Having a single customer-centric ticket helps with alignment and clarity across the team, and GTM can follow releases they care about easily.

Everything should have a clear DRI and fall under a project. Each project should have its Kanban board, Slack channels for engineering, and GTM.

The product lead should own prioritization and de-scoping of features. If some customer requests cannot be filled out due to resource constraints, the product lead should communicate them to the customer (or sales/marketing/gtm peers so they can relay them).

Every week ends with a public demo of the work done. Demos are across the entire eng org. Anyone is welcome to attend. See meetings for more details.

4. Release¶

Every team should be shipping features every day. Given every dev tool and infrastructure now works with Git branches, we should be able to go from a PR to a release in a few hours/days.

All new features should start with feature/ prefixed branch. All bug fixes should start with fix/ prefixed branch. This allows anyone across the org to help QA or follow along with the progress.

Quality¶

It is the responsibility of both the product lead and the engineering lead to ensure the quality of the product/feature is being released. Automated and AI-driven tests are helpful, but the leads should obsess over the details and ensure the feature is high quality. With current tooling, the feature can be tested on the feature branch before merging to the main (i.e., deploying to production).

5. Bug fixes / On-call / Security¶

We should always be fixing bugs. Every week, one engineer from each pod/team should be on bug duty. If things go down outside office hours, the same engineer should be on pager duty. Before every weekly planning meeting, the product lead should review the bug list and ensure enough scope is available for the allocated engineer. If spare eng capacity exists, the product lead and engineer can try and de-risk some longer-term ideas or pay off technical debt.

Below are some severity levels for production issues that a product can face:

1. SEV-1 (Critical): Major outage or critical functionality broken; customers cannot use the product or a crucial part of it. Requires immediate, all-hands response.
2. SEV-2 (High): Significant degradation; a major feature is partially down, or performance is seriously impacted for many users.
3. SEV-3 (Medium): Minor feature malfunction; noticeable but not blocking customers from primary tasks.
4. SEV-4 (Low): Cosmetic or trivial issue, minimal impact.

The on-call engineer should be able to make a call on the severity of the issue and then communicate the same to the product and engineering leads. There should be a Slack channel to manage the communication related to the issue.

6. Tools¶

Linear is an excellent tool for hosting product/eng context for every project/feature. It works well with Github for PRs and releases. Every project should have a linear board and slack channel.

Disclaimer: this process is a work in progress and will be updated based on learnings from the team. There are many minor details that have been left out for brevity. Each team fills in the gaps based on their own context.