It just has to work
We've been trained all of our work life to "do things the right way".
The right process. The right level of detail. The right amount of alignment.
You know what happens next. Six months later, nothing has shipped.
The Hidden Cost of "Doing It Right"
When you're a scrappy startup, everything is allowed. Quick hacks, half-baked ideas, and sometimes editing things live in production. But as a company grows, it starts to establish processes to prevent failure. A "best practice" here, or an "executive review" there.
Some of that is necessary. Every process is someone's scar. They've lived through outages, security incidents, compliance failures, and broken trust.
The problem is what happens over time. Last-resort safeguards quietly become prerequisites for action. Teams wait for a complete understanding of the problem. It rarely happens. When you treat perfection as a risk-avoidance strategy, nothing ever ships.
Momentum Beats Consensus
One product manager I worked with hit this problem. They were struggling to get stakeholder time to talk about the requirements for a new capability. Everyone had opinions, and they wanted to make sure that they were captured.
I asked them to write a one-page, opinionated spec and share it. Within a day, stakeholders were commenting in the doc with their opinions.
A one-page spec can trigger in a day what weeks of scheduling can’t: informed disagreement.
The first version is almost always wrong, but it surfaces the right disagreements fast.
It doesn't need to be a spec. Sometimes it’s a clickable prototype. Sometimes it’s a command-line script, a mocked API, a Loom walkthrough. Just make something that people can react to.
It doesn’t need to be complete. "Working" means:
- Usable by a real person today
- A measurable metric moves
- You can tell that it worked within hours or days
- It fits within your guardrails
Incremental progress is how you get to the right answer faster. It requires clear success criteria and fast feedback loops. More importantly, it requires a willingness to delete work. Ship, learn, iterate, then ship again.
Some work has tight constraints - safety, legal, ethical, security - but the need to learn doesn't go away.
The Real Questions
Action creates something people can react to. Once something "good enough" is unblocking real users, the questions change. Instead of asking "Is this ready?" or "Will this scale?", ask questions that inform the future.
- “What will we learn if this works?”
- “How quickly will we know if it doesn’t?”
- “What gets better the moment this exists?”
Most teams fail not because they move too fast, but because they wait for certainty that never arrives. Teams that wait for perfect don't have better outcomes. They just have fewer of them. Progress starts when there’s something real to push against.
Treating every decision as permanent is how you end up six months in with nothing shipped.