Real Problems vs. Anticipated Problems
New Story is a nonprofit that builds homes and communities for families living in survival mode around the world. We believe technology is a force multiplier for impact. Learn more here -> newstorycharity.org
As we’ve built New Story’s tech platform, what we call the Monolith internally, we are constantly battling shipping on time/hitting a deadline vs. scope of work/what’s planned to be done. This is an age old tension to be managed as it’s not ever going to vanish.
One example of this tension recently was whether we should built our Monolith to automatically assign surveyors to upcoming survey requests (a much larger dev build vs manually letting our team assign survey requests). This would be incredible, however we were assuming this would be a problem. For the first version we decided to built the smallest useable feature to test our assumptions and not anticipate problems.
The question to ask yourself, “Is this a real problem or are we anticipating this to be a problem?” Usually upon asking that question it becomes crystal clear if it’s a real problem or something we could anticipate happening. And when I say real problem I mean that you or a team member has experienced that problem more than once (at minimum).
Since we’re naturally problem solvers we automatically want to solve ALL the problems (whether they be real or anticipated). But, like our CTO, Morgan Lopes, says, “A perfect boat on the bottom of the ocean is still a perfect boat on the bottom on the ocean.” In simple words: don’t let perfection/solving all the problems keep you from shipping that new feature.
Takeaway: Ask yourself, “Is this real? Or is this me thinking 2 steps ahead and trying to solve something that may or may not be a problem?”
