Having recently transitioned from a FAANG company to an early stage tech startup, I can relate to this question at many levels. First, I will unpack the question a bit further and share my own learnings -

1. “Early stage Pre-PMF chaos”

It is important to realize that the pre-PMF chaos is a core feature of an early stage startup, not a bug. Some of the best hires in an early stage startup are individuals who can thrive in ambiguity. They try to embrace the chaos as a catalyst agent that can accelerate their path towards PMF. In an early stage startup, your goal as a PM is to drive enough clarity and prioritization to keep reducing the overall ambiguity, and not necessarily eliminating it altogether.

2. “Founders and internal stakeholders are expecting a lot”

Expectation management is an important, yet often overlooked, part of early stage startup's operations. It is an ever-evolving process, which should be well documented, regularly reviewed and (over)communicated across all stakeholders of a company, including the founders and board members.

3. “New features to be released in an unreasonably short period of time”

Feature velocity is one of the core differentiations between early stage startups and big tech. As a PM, your goal is to balance feature velocity against timely execution of must-have features that have a clear impact on your business goals. This will require you to push back on (or break down) features that are either ambiguously defined or don’t have a clear impact on your team’s goals. At my startup, I strictly use our business goals as a yardstick to drive clarity and prioritization of our feature roadmap.

Now that we’ve unpacked the questions and shared some learnings, I’ll provide more tactical suggestions to address your concerns:

Establish engineering and design sprints: I highly recommend establishing a mechanism to break down your entire development process into granular pieces i.e. sprints and assign clear scope and feature prioritization for each sprint. It is important to ensure that you’ve set clear expectations with all stakeholders that the scope of a sprint will be locked until completion, unless there is a strong reason for a change. In an early stage startup, it might not be feasible (or healthy) to run longer duration sprints of 2+ weeks, so you can keep the duration of each sprint to be under 7 days. You should also account for 10-15% of the sprint time (buffer time) for change of scope of the planned features as that will be a common occurrence at this stage of the company. During the course of a sprint, if any planned feature is taking longer than expected or the scope has increased along the way, then the buffer time can be used to account for it. Any new feature request, outside the scope of the current sprint, should automatically move to a product backlog which must be reviewed with all stakeholders before assigning and locking the scope for the next sprint. This process requires discipline and respect from all stakeholders and it's the PM and Engineering Manager’s job to drive that respect over time. 

Defining the Minimum Lovable Product and prioritizing brutally: As a PM, it is important to distinguish between false rush requirements and true business needs, especially when you’re in the pre-PMF stage of your company and have limited resources at your disposal. The first step is to have a clear definition of the MLP (minimum lovable product), and to gain your team and leadership’s alignment on it. Once the MLP is defined and under development, any new feature requests outside the scope of the current MLP should be transferred to the product backlog. This will require you to strongly push back and brutally prioritize between features, when necessary. Ensure that your prioritization mechanisms are explainable and consistent. The MLP definition and the product backlog should be reviewed with the team and leadership, every 3-5 weeks, to account for new learnings, industry trends, customer requirements and competition.

In conclusion, I’d like to reiterate that the pre-PMF chaos is a core feature of an early start startup, not a bug. Your core job, as a PM, is to navigate through ambiguity while balancing continuous development and accounting for the evolving requirements.

This requires you to focus on:

(i) managing expectations with all stakeholders through well documented processes and over-communication;
(ii) driving more respect and discipline towards the engineering and design sprints; adjusting the sprint duration based on your evolving business needs and pace
(iii) setting a clear definition for your MLP, gaining alignment from your leadership and driving brutal prioritization between planned and new features, through explainable and consistent prioritization mechanisms.