Execution & Velocity

When your deadline feels impossible, don't make the feature worse — make the feature smaller. Keep cutting until one more cut would make it useless, then ship that. A smaller thing that works perfectly teaches you more than a bigger thing that half-works.

Your job is to clearly define what problem you are solving and what the limits are — timeline, scope, user need — and then trust your team to figure out how. Once that is set, your role shifts to removing blockers and making sure the work actually ships, not redesigning the strategy every week.

Before a meeting, ask everyone to independently write down their opinions, rankings, or estimates — no group chat, no reply-all. In the meeting, skip the parts where people agree and spend all your time on the disagreements. This stops the loudest or most confident person from hijacking the outcome and surfaces the real signal hidden inside the room.

When your team is tiny, you don't need fancy tools or formal processes — a simple shared spreadsheet and weekly alignment is enough. As you hire more people and the founders can't be in every decision, you need to write things down and plan further out. The rule is: add process only when you feel a specific pain that process would solve.

Your job is not to manage a sprint — it is to make sure your team never has to stop and ask 'wait, what are we actually building and why?' If engineers are blocked or confused mid-build, you were too late. The work of a PM happens before the work of engineering.