Choose Well, Ship Fast: A short guide to High-Impact Work

“Hey Razvan, I need to spend two more weeks on this dashboard generator to make it adaptable and answer any other future customization needs we might have from other customers“. He agreed, but I ended up wasting two weeks of engineering time without shipping a useable dashboard generator. In the end I did it manually in one day.

I've been lucky that in most of my jobs, I had a say in what I was working on. Sometimes, this meant inflating some estimation to refactor a piece of the subsystem. Other times, it meant convincing the PM that spending an extra week now would save one month of work over the next year. I've made mistakes and worked on scrapped POCs (proof of concept), but there were also great successes; the most impactful things I worked on were those I demoed after a few late-evenings coding by myself. Since then, I've developed a few tactics that minimize wasted effort.

You want to work on the right thing in the right way. Before starting to work on it, think of where it lies in the 2×2 matrix drawn below:

The right thing - an impactful problem that is achievable. Look for patterns: what frustrates you or your teammates repeatedly? What takes much longer than it should? What comes up in every retrospective? The best opportunities are those where solving it once will save time many times over.
The right way - start small, iterate quickly, gather feedback, and avoid perfection.

I've found that breaking down the work into three stages helps minimize wasted effort:

1. Demo - Show the vision, not the implementation. Cut every corner necessary—it doesn't need to work; it needs to convince people that once it's working, it will be valuable. A good demo answers: "Is this worth pursuing?"

2. POC - Make it work well enough for early adopters. Find team members who strongly feel the pain point and are willing to try something new. Their feedback will tell you if you're solving the right problem correctly.

3. Launch - Polish it for general use, but don't aim for perfection. Share it widely, measure adoption, and gather feedback. The real improvements will come from actual usage patterns you couldn't predict.

You can stop at any stage if the feedback suggests it's not worth continuing. Each stage is a checkpoint that helps you avoid overinvesting in the wrong direction.