Shortcuts, Not Subpar Work #

One of the few rules that will determine the success of a project is how fast are you iterating through experiments. Not incremental steps, not sprints points, not logged hours, not moving, but iterating.

Iteration as in a complete feature that solves a problem at its most basic level without all the bells and whistles, without all the decorations, heck even including the rough edges. Just the bare minimum that will allow you to sneak peek into the future and see which path forward to take. That's where and when you see if you are making a new painkiller or a vitamin.

What is often seen as taking shortcuts by implementing a very straightforward solution to the problem ends up being more than enough to validate the idea and because the implementation is simple in its initial phase you can either easily rollback or keep building upon it based on the learnings of actually putting the feature in front of your users. Or even better, due to the lack of sunk cost fallacy, you can just discard it.

Don't worry about sounding stupid when proposing the implementation because in most cases it will sure do sound like a stupid idea but it's way better than implementing a stupid feature for long a period of time just to get to the same conclusion.

Taking a shortcut here and there doesn't mean doing poor quality work, it doesn't mean condensing the whole feature into a tighter timeline, it doesn't adding more people to the mix, it doesn't mean skipping quality checks and design reviews. A shortcut is a hard cap on scope within the shortest timeframe possible.

By taking a shortcut you are looking for proof that a request by a client or an idea from your team is a missing piece of the puzzle or a nice to have thing.