Most startups don’t have the luxury of hiring an experienced PM early in their journey. Many founders have to turn to brute force to figure it out, even when they themselves don’t have practitioner product management experience.

However, managing product development correctly is incredibly important in the earliest days and can make or break your company. When you have extremely limited engineering resources, it’s even more critical to stay focused and clearly set your priorities. To add to the pressure, you’re likely still on the path of finding product-market fit (PMF), which requires racing with high throughput and fast iterations before time 9and money) runs out.

So, what are the things founders can learn to do well BEFORE they can hire a great first product hire to make sure the company stays focused and iterates fast?

 

1. At any moment, be crystal clear (and stay consistent) about what the “top company priorities” are for the quarter

This sounds incredibly straightforward in theory, but it’s actually hard to practice in reality. Without being disciplined and mindful on focusing on a few most important things, many founders get pulled (or pull their team) into the ideas of the moment or rush to put out the latest “fire.”

How do you think about these top company priorities? They could look quite different based on whether you’re pre- or post-PMF:

  • Pre-PMF: Key hypotheses of the business you want to prove/disprove — they can range from customer acquisition, product engagement/stickiness, or business model.
  • Post-PMF: Key milestones the business needs to hit (e.g. growth/revenue target) to get to the next stage/financing round.

It’s not enough for the CEO to know what these are — make sure there’s strong alignment and clarity among the founders/senior leadership. These “top priorities” become the guiding north stars for every product decision that follows.

 

2. Link product ideas and features back to the top priorities; stop working on everything else

Take a look at your product roadmap or your JIRA/Trello/Asana board right now. As you read through the long list, can you directly attribute each line item to how it advances the top priorities of the quarter? If something doesn’t map, move it to the backlog and DO NOT spend resources on it right now (even though you/your investor really want that feature, or that it just feels like such a great idea)!

What about bugs, UX fixes and other types of “maintenance work” that seem like the right thing to do? This is a common challenge for companies of all sizes/stages, but the tradeoff could be especially tricky for early-stage startups given the extremely limited engineering resources. Two possible approaches:

  • Approach 1: Define a threshold of “critical/must happen now” — anything that does not clear such threshold needs to go into the backlog. E.g. For an e-commerce company, anything that involves payments/its ability to charge customers could clear the threshold.
  • Approach 2: Allocate [x]% of your engineering bandwidth for such activities and do not go over. It could be as small as 5% of your weekly bandwidth, but it’s helpful that the team feels like they can slowly chip away some of these and make progress. This is a choice around your product throughput, and you can iterate through a few sprints until you find the right balance.

 

3. Create the space (and find the time) to assess the impact of each initiative so you can prioritize in an intellectually honest way

I’ve previously written about a general framework for product prioritization, so I won’t take up too much space here rehashing. As a founder of an early-stage startup with a small team, you might not feel the need to go through a process with such rigor other than debating in your head (or with your cofounders on the hallway).

However, without setting aside a regular cadence/process to review what should be built next, you’ll quickly feel that tickets on your product backlog are growing like weeds and you’re losing grasp of whether your engineering team is spending time on the most impactful things at the moment.

How should you think about impact? In many cases it can be framed as learnings (e.g. disprove certain hypothesis so you can move on); otherwise they should either move your top line (revenue) or your bottom line (margin/profit) directly or indirectly (e.g. product engagement, retention metrics).

 

4. Force yourself and the team to design and ship small

When you have a vision of a product that is so robust that will knock all the competitors out of the park and finally validate the market, you will be tempted to architect for this grand release — “all our problems will be solved when this magical product is released!” The problem is, it will most definitely take years and tens (if not hundreds) of engineers later to have a chance at getting close to that vision — and by then the market has likely shifted.

Striking that balance between marching towards that grand product vision and making immediate business impact is both extra challenging and extra necessary for an early-stage startup. The risk of tying up all three of your engineers’ bandwidth for nine months on one single release without any market validation or customer feedback (when you only have an 18-month runway from your seed raise) is just way too high.

Here are two ways to think small:

  • Experimentation Design. Before you commit to any significant product feature/initiative (and I’d consider anything that requires more than one month of engineering bandwidth as significant), critically examine WHY you plan to commit to such initiative in the first place. Do you have enough data or customer/market validation to support such assumption? Can you significantly increase your confidence level (and thus de-risk the potential waste of engineering time) by validating such assumption through a one-week, light-weight experiment?
  • Break Up the Footlong Sub. I use the analogy of a “footlong sub” to describe a product build that is likely too big/long/ambitious and could use some slicing. Instead of waiting to ship this large product bundle in what would feel like eternity in startup time, take a hard look to see how you might be able to break up this footlong sub and ship smaller bites. Each release should be just enough to either 1) make some immediate business impact, or 2) validate/invalidate a key hypothesis that would help you deploy future resources more efficiently.

 

5. Commit, Communicate, and Constantly Reprioritize

Regardless of your company stage and team size, you should always have a rolling 3–6 month product roadmap that’s clearly defined. This is a hard discipline, especially for early-stage startups, because it could feel that things change daily and there’s always a fire somewhere to put out. However, if you don’t set goals you won’t hit them — especially if your team doesn’t have forward looking visibility and understand what they’re working towards.

How your product could look like a year from now might still be murky, but you should have high-confidence level hypothesis on what you want to accomplish in the next 3–6 months. When new data points/ideas emerge or market landscape shifts, do not shy away from reprioritization — the roadmap should be rolling and dynamic in nature and serves as a baseline to constantly examine new priorities.

Hold yourself and the team accountable to that roadmap, communicate to investors/Board to set expectations, and help them help you focus.