Project management is like black magic for early-stage startups. The difference between the lords and the plebs, the secret to reliably executing and doing things fast.

As a startup you are literally inventing the future, on a deadline, with zero budget, a small team, and massive uncertainty. To be a successful early-stage startup you simply have to get exceptionally good at prioritizing, planning and shipping projects. It’s the only way; and without it, many fail.

So today I am outlining my current philosophy on how to effectively manage projects in startupland, based on our learnings of what’s worked and what hasn’t. I’m not the ultimate authority on producivity, but I have run a few startups to-date and have some thoughts that feel worthy of record. So here it is:

Before we begin, a few caveats.

I. First, every team dynamic is different, lean into yours. The spectrum of project management philosophies ranges from full waterfalling (everything is charted out up front) to cowbody coding (just ship / don’t ask questions)

In between there are ideas like Scrum, Agile, Shape-Up, OKR-driven, etc. These vary but generally I’d call this zone the orbit of opportunity, where good things happen:

Our team has taken bits and pieces from a few of these project management philosophies; we borrow heavily from Shape-Up by the guys at 37signals, mixed with bits of Agile and the EOS Quarterly and some other sprinkles of things we’ve learned along the way. Point is, there is no ‘one way’.

II. Second, pick tools that work for you and commit to them. There are a million project management tools you can use (we’ve tried many of them) - Jira, Github Projects, Notion, Slack, Basecamp - each is a slight variation of a glorified to-do list. Most recently we have been using Linear, which is probably my favorite ever.

III. Third, buy-in is everything; none of this works if everyone isn’t on the same page. It’s both science and art. On one hand, if you aren’t systematic you won’t get things done, there must be a forcing function. On the other, if you get too rigid, you lose creativity and morale (your soul). Setting expectations and communicating often is critical.

A few things we’ve tried that didn’t work very well (for us):

1) Setting rigid deadlines too early - they are always wrong and usually more harmful than helpful (as much as I’d love for them to be helpful). There is an art to setting the next meeting, but its a futile effort to try to pick an end date when you aren’t even sure of all the critical components. Pick a fuzzy end range when you start, and only land on an end date when you can begin to see the light at the end of the tunnel.

2) Passively managing - You don’t get as much done as quickly when the CEO isn’t heading up project scheduling and scoping. As a CEO its easy give your CTO a list of things you want done by the end of the quarter and say ‘have at it’. But this lacks the healthy back n’ forth that is required to get things done and do them quickly. A CEO should be as involved in outlining and pushing projects forward as possinble

3) Tools that we’ve tried (and failed with): Jira, Trello, Notion, Github Projects, Slack Canvases, ClickUp. We always seemed to end up doing different parts of the planning in different places. The tool that seems to work best for us (and the tool that we took a chance on because so many friends recommended it) is Linear, its the one exception where we can seemingly manage all aspects of projects in one place.

Here is how we manage projects within our early-stage startup:

Every 3 months we have an all-team roadmapping session for 1-2 days in person. Throughout the quarter we jot down ideas for features / initiatives / etc that we could work on and put them on a little board.

Often times these are just one sentence or a few words at first; it works better when you can just get them out of your brain somewhere (and it’s really hard to come up with great ideas on the spot, they will occur to you!) and have somewhere for them to dry out in the open for everyone to see.

As we get closer to roadmapper (2-3 weeks out) we go through and fill in details for each idea: how much effort do we think it is (T-shirt size), how much impact do we think it is (H/M/L), what’s the motivation for each (any customer quotes we can point to?) and pre-requisites (what needs to be done first for this idea to be possible?).

Then we get together for an afternoon and put them in rough order of priority. Going into the roadmapper we try to have 2-3 major ‘initiatives’ for the next quarter that we can tie everything back to (ex: move into new vertical, execute on a new partnership, etc.). A project’s impact and urgency is defined by its ability to move the needle for one of the initiatives (or lack thereof).

We go through each project idea one by one and finalize our impact vs effort rank. From here we split them into tiers diagonally as you can see here^.

I try to think of it like a conveyor belt more than a bucket of things to do - we don’t necessarily expect to get all 30 ideas done over the next quarter (deadline averse) but we know we want to get pretty much everything in Tier 1 and are happy if we can do part of Tier 2.

Priorities will inevitably change as you get more info from the real world and new things will jump to the front, but at least it’s a start. Once we have our list in order then we begin executing (and the slate is wiped clean to be started again the next quarter!)

Once a project has been put onto the conveyor belt, kick it off whenever you have the capacity. Kick-off for us typically looks like a ~1 hour meeting with the key stakeholders (ie. CEO, CTO, + any developer who will ‘own’ the project).

Heading into kick-off a project will typically have some notes for key requirements and why we want to do it. At kick-off is where we fill out all the rest of the details that we can. We follow a template that we’ve adopted from Shape Up (shown below) to make sure we think through all the important aspects:

Importantly, at this stage we are NOT setting a deadline generally. Just rough time periods when we’d like to have things generally done (ex: by Q4). You can worry about due dates when you get close to the bottom of the hill (see next section).

A few important elements:

Thin Through Line: like to think of showing progress and weaving a ‘thin through line’ from the bottom to the top of it - start by integrating the most important critical components first then build off of that (ex: better to make one part of the backend the works with part of the front-end first, then to build the full front-end before worrying about the database):

Dragging Projects Forward: In my experience, projects must be dragged forward. You cannot expect that they will simply make progress on their own. Bite off a doable chunk to try and get done each meeting, schedule the next check in at the end of each meeting for however many days later you think you’ll need to get that done. Regular-cadence (weekly) meetings are not ideal bc pieces dont natrually fall into one week chunks.

Project Updates: in the in-betweens, have your team write short little updates on progress. This is one of my favorite features of linear, the ‘Update’ option. Great for keeping disparate stakeholders up to speed on progress in an async world. You may even consider having your team write an update on each of their projects every 1 or 2 weeks. Acts as a simple forcing function to make progress and formalize it.

As I said in the Kick Off section, you shouldn’t set official deadlines until you can see the light at the end of the tunnel for the project.

The Final Deadline: The Shape Up method says something similar in a different way (see below): projects are like hills, the first part you are working up hill figuring out what to do and answering unknowns. Eventually you reach a peak where you have all the key parts figured out and now you just have to execute. Then (and only then) can you begin to think about deadlines. I try to get as far as I can without setting a deadline. They are best used as a motivator to close something out, and until you know what’s left to do its hard for them to be useful:

Always Keep the ‘Why’ in Mind: Throughout the project you should continuously be looking back to ensure you are truly meeting the requirements and that they tie back to your project’s original motivating initiative. Try not to do more than you’ve slated or things will get messier and take longer.

Wrapping Up Best Practices: As you approach the finish line, you should always end a project at a point where someone new can jump in and pick it up where you left it off. This means cleaning up your workspace; adding any important documentation, writing a final update or walkthrough, outlining any potential ideas for things to work on next (or things that you weren’t able to get to). Make sure there is a record for posterity.

Anyways, that’s all I’ve got on this for today, hopefully this gives a few ideas for where to start and how to optimize. Always happy to discuss ideas.

Cheers,
Ramsey