How to stay lean as a startup - Part 1: Project Management (the #1 culprit)

Lessons from building and working at startups

Does this sound familiar?

“- Can we build this?
- No, the sprints are full for the next three months"

“- Our users would really love this feature
- We’ve already got a bazillion features planned and we’re already late building and shipping all of them, add it to the backlog”

“ - Can we change the color of that button?
- Hum, maybe next month, it will take five days of work”

Then keep reading.

Startups are a story of David and Goliath. Being small gives you the advantage of moving fast, adapting quickly, shipping in a heartbeat and often.
That is your weapon; that is what can make you succeed.

So why, oh why in most startups, after a short while:

1. Shipping starts to get so slow that even my grandma is yawning at that lack of efficiency?

2. Process makes motivated people feel like they're apathetic zombies whose souls left their bodies long ago?

3. Everyone is so frustrated that they are longing for a 2022 job market to happen again so they can escape that hell?

It doesn't have to be like that.

No matter if you're a solo founder or a 100-person team, a lot of the pitfalls are the same, a lot of the dead ends are the same, a lot of the lessons are the same.

This post is the first one of a series of posts about "How to stay lean as a startup"
1. Project Management (the #1 culprit) - this post
2. Hiring
3. (I'll update when more posts are be available)

The Seine riverbanks in French countryside. Credits: me.

Why do we need project management?

Most of the time we need a project management system because we have a set of problems to solve.

You should not try to solve a problem you don't have yet.

Real problems can be

1. Shipping is slow

2. Engineers are not sure of what should be delivered and why

3. Communication between people working on the same thing is hard or non-existent

4. Priorities are unclear

5. Scope creep (some stakeholders whose specialties are in sales or management keep thinking their ideas are brilliant and everything needs to be done at once)

6. A lot of tasks are started but none are finished

7. Poor visibility of progress

8. Engineers work on something not valued by the business

9. Lack of flexibility when priorities change

Unfortunately in real life we end up with a project management system because some manager wants to know exactly what everyone's velocity is, as if it were a good indicator of productivity.

Why do we always end up with SCRUM?

SCRUM aims to solve the issues generated by waterfall project management in which the startup workers don't really communicate with each other and individual goals are not focused on the product or feature.
Which are real problems to address.

In practice, SCRUM is poorly designed; it makes us spend a lot of time enforcing processes and ends up being a glorified waterfall process with a lot more constraints for the people trying to actually get things done.
Most of the tools used in a SCRUM organization (like Jira) actually enforce these methodological biases and drive the final nail in the coffin of your productivity.

So why do a lot of startups actually use SCRUM?
Mostly

1. Cargo cult (so, ignorance)

2. Laziness to think for ourselves and address the root of real problems.

Choosing SCRUM or something similar in 2025 is the lazy response to a chain of bad decisions (I never said I was here to comfort you and be nice).

Adding a scrum master just adds a non-productive role and removes ownership from everyone else, which is exactly the opposite of what you should be doing.

Agile, really?

SCRUM is supposed to be an agile methodology.

“- Can we build this?
- No the sprints are full for the next three months"

“- Our users would really love this feature?
- We already got a bazillion features planned and all late to build and ship before that, add it to the backlog”

Is “agile” the first adjective coming to mind in this situation? I guess not.
Agile coaches and scrum masters will tell you it's because you're doing agile wrong, but when everyone ends up in this situation, it's not bad usage, it's just bad design.

Another common symptom is

“ - Can we change the color of that button?
- Hum, maybe next month, it will take five days of work”

This one is because in that system, your engineers end up so overwhelmed that their focus is not on delivering positive impact to the product, but on protecting their velocity in a project management tool.
Their obsession becomes: “estimate with made-up numbers” and “finish the sprint so the burndown chart looks good”. In this context they can't think clearly because they have so many different things to estimate and keep track of that their brains have already collectively migrated to another plane of existence.

So, what to do?

I'm a fan of first principle thinking for every problem I encounter.
Thinking for yourself is a process. It's hard, painful and frustrating. Therefore we're tempted to ask an LLM or to copy what everyone else is doing and end up thinking from other companies’ assumptions and context.
However, every context is different, there’s no silver bullet.
So to find your own customized bullet that will end your problems you need to start from a blank page and do the hard things.

Where are you now? What are your problems to solve?
Don't copy, don't adopt a framework right away. Build your own basic system. Focus on your needs, test it, and adapt accordingly.

The real trick is: to get project management right, you first need to get the way you work and think right.

So let's take a step back and speak about those.

Obsess over user needs not business results

No matter how you decide to organize, your focus and your team goals should be about fixing users’ problems and not force-feeding them features.

With this approach it will be easier to focus on the build - ship - get feedback - iterate loop.

If you try to just blindly implement your ideas - please wait while I put my Nostradamus hat - you’ll end with a bloated backlog of tickets, burned out teammates and a growing anxiety while watching the business going absolutely nowhere while your runway is melting.

Foster a culture of ownership

It's a common trap. When workers are disconnected from the activity and evaluated on criteria other than the impact they make on the product, they start to lose ownership of the product or feature.

Adding management layers in the mix is the worst thing you can do. You want to enforce a sense of ownership.
Engineers should not just code, designers should not be Figma output machines, etc.
Everyone needs to think together, add their angle, their views, their insights, their experiences on what should be done now and why.
Ideally these discussions happen with data and user insights.

Enforce communication

If everyone is responsible for the product, part of the product, or feature it will enforce communication. The team needs to self-organize and set deadlines for their tasks. Communication will have to happen.

Your red flags are the ones not participating in it or not bringing anything to the conversations. Be sure to push toward more participation, create a space where they feel safe to take risks by speaking up or expressing ideas, foster a culture centered around the product.

If your engineers or designers just want to stay in their corners being ticket pushers, then you have a big organization issue on your hands and it sucks.
Choose your teammates accordingly.

Focus, Focus, Focus

You cannot expect anyone to work on multiple things at the same time and deliver quality work. Our brains can't really handle that. And if you think you can, think again.

A team should work on one thing at a time.

If you want to implement several features at once, you need a team of different people for each feature. Or you'll get shitty results and burned out people on your hands.

If there are a lot of bugs and technical debt, you need to assess: what will kill your company first?

• A bad user experience (sometimes these bugs are acceptable, they don't ruin the UX or are edge cases)

• The lack of interest in your product because it doesn't bring value to the users?

If you feel overwhelmed with bugs and issues, it may be time for a dedicated team to solve these or to slow down and fix things.
I voluntarily don't go into details, exploring quality and technical debt management would require a dedicated post (or posts).
Just remember that the same person during the same cycle should not work on several different topics simultaneously.

Think long term, plan short term

Planning long term is a startup killer, one for which we have just one cure: well - just stop doing that. Easy.

If you plan months of features in advance, you are ignoring your users.
You should be driven by a feedback loop, build, ship, get user feedback, iterate on what you shipped. You can't predict when this iteration cycle will stop and that the feature will hit the score, so why are you already planning for after that?

If you start to say things like "detailed roadmap”: please punch yourself in the face and try again. What you're doing is only keeping you busy and you'll soon pay a Scrum master full time to write and move hundreds of tickets from one sprint to another every cycle and eat at least 20% of your workforce time to make estimates with made-up numbers - also called "story points”.

Best teams plan for one dev cycle, which could be one, two, three, etc weeks.
If you're just beginning to experiment, plan for one week ahead, not more.
Every team is different so take that as a starting point and experiment to find your best fit.

Some bad news

Project management is a complicated topic, it's deeply intertwined with the company’s organization, management style, trust between teammates, culture, etc.

Sometimes bad project management practices are just the result of bad hiring and mismanagement, in this case no process or framework will fix that. You'll probably have to restructure your teams or the way you work and think entirely.

Takeaways

There’s no one-size-fits-all in project management, but with a healthy approach, it’s not that hard to do way better than what SCRUM or Waterfall methods have to offer.

Just keep in mind these basic principles:

1. Obsess over user needs, not business results

2. Foster a culture of ownership

3. Enforce communication

4. Focus, Focus, Focus

Then, design a work management template or set up your tools in the lightest and simplest possible way for your needs.