How I learned to stop over-indexing on delivery
For a long time, I equated progress with delivery.
If things were shipping, the roadmap was moving, and stakeholders were satisfied, I assumed we were doing well. Delivery was visible, measurable, and rewarded, so it became the default proxy for success.
What I learned early in my career is that progress depends on the quality of the questions you ask. What are you actually trying to achieve? What behaviour are you trying to change?
The problem is that delivery is a very convincing illusion.
You can deliver consistently and still fail to change anything meaningful. Features go live, but behaviour stays the same. Metrics don’t move. The business impact is marginal, at best.
I didn’t stop over-indexing on delivery because I became less disciplined.
I stopped because I realised delivery is only an input, not an outcome.
Here’s when I learned this the hard way:
At a B2B SaaS company, we rapidly shipped messaging integrations with 3 popular CRMs. Our assumption was solid: these tools covered 60% of our customer base, including large enterprises. Theoretically, we were addressing the majority need.
What actually happened:
Enterprises wanted deeper integration capabilities, not just basic connectivity
The other 40% immediately requested a long list of additional integrations
Account executives assumed we’d stopped prioritising their clients
We opened a whole new can of worms for large customers who now saw the feature as incomplete
We built it. It worked. But the effort-to-impact ratio was terrible.
Looking back, those integrations shouldn’t have existed, at least not in that form.
The questions I wish I’d asked:
What specific workflow are our highest value customers actually trying to complete?
Do we have the capacity and positioning to become an integration platform, or are we solving a different problem?
What would success look like six months after launch, not just at launch?
If I’d asked these questions, the feature wouldn’t have existed in that form. We would have found a better way to get the job done for users, or realised we weren’t set up to solve that problem at all.
What changed for me:
I didn’t stop caring about delivery. Poor execution still kills good ideas. But I stopped treating shipping as the finish line.
Now I spend more time on:
Questioning assumptions before we commit
Defining what should change if this works
Being willing to kill ideas that don’t have clear answers
Delivery answers: Can we build it?
Outcomes answer: Should we have built it at all?
The hardest part wasn’t changing how I worked. It was changing how I measured myself.
Shipping is easy to celebrate. Impact is harder to sit with.
But in hindsight, that shift did more for my growth than any process improvement ever did.