Over the years, I’ve been on the receiving end of a slew of feature requests from our customers, my friends & family, our employees, our partners, and our investors. It’s fascinating to hear from all of the various people. Each person explains why they believe that the feature they suggested should be the most important priority for Punchbowl. Everyone has “must-have” features or functionality, and everyone has items that they consider the #1 priority.
Here’s the problem: everything can’t be the #1 priority. In my years of managing development teams, I’ve learned that you can’t just add more people to build software faster. The hard part of software development is thinking through the design issues, carefully considering how the feature will scale over time, and providing yourself enough time to adjust the implementation when you see the first iteration of the feature working. Great products are built carefully, with careful thought before implementation and ample time to test and iterate before unveiling it to customers.
I can always tell apart the people who have developed software in their past from the people who haven’t developed software. Those who haven’t ask questions like “Is it possible to do XYZ” (in software, it’s almost always possible to do anything with infinite time and talent). Those who haven’t ask for endless features and say things like “That feature shouldn’t be that hard.” Contrast that with those who have software development experience: They ask thoughtful questions about feature implementation — for example “How will this feature work for existing users?” and “How does this feature impact other features around it?”
Everything can’t be the #1 priority. Whether you have a small team or a large team, you have to make a priority list — an actual priority list, numbered 1-xxx. Force yourself to answer the question: what’s the most important thing on the list? What is 2nd most important?
Even the best developer (hi Blake!) can only work on one thing at a time. Each developer needs their own priority list — also numbered 1-xxx. Don’t fall into the trap of thinking that you can have more than one priority at a time. I’ve witnessed the difference between development teams that know how to make priority lists and those that don’t. Those that don’t take on too much too fast and end up shipping a product that isn’t ready for prime time.
If you’re on the receiving end of feature requests, prioritize everything and make sure your team does the same. Remember: everything can’t be the #1 priority. Repeat that to yourself and keep repeating it to all of the people around you so they know the priorities.
