There are a lot of different ways to build software and there is definitely not a one-size-fits-all model that works better than another… and other than just sitting down and writing code for hours and hours and hours of time… the only thing that matters is that code is being written, full-stop.
What it comes down to, then, is both personal preference and ultimately how you (and your team) think through building software. In short, it’s context that really, really matters.
For my current project we are using a framework of thinking that we call Community Driven Development and it’s working out quite well (CDD isn’t a common term in software development but it’s used elsewhere in the world as a business and product strategy – my brother frequently uses this term for software so I’ve adopted it here).
It’s pretty self-evident based on the name but the way in which we operating consists of these pretty simple and straight-forward steps:
- Our team designs the core infrastructure, hypothesis(es), and roadmap.
- Then, we begin building.
- We invite early test users into the early versions (via structured cohorts).
- We encourage and solicit feedback through multiple channels and through direct interviews.
- We capture suggestions, feature requests, and, of course, any bugs or issues that the users encounter.
- We then take those ideas and execute against them.
- Rinse and repeat process until you build an amazing product!
That’s about it.
What’s so great about this process is that you really do get to build a more impactful and effective product, from all types of angles! Here’s an example improvement that we made after one of our users built a custom python-based bot to spam our new platform:
Without one of our user’s giving us this type of feedback we wouldn’t have known to dedicate any design and engineering time to something so critical this early in the product’s life.
Consequently, rolling out these limitations will make the entire network more secure and less open to abuse – it’s amazing how powerful and effective community driven development can be!
I love building this way because of this singular reason: You end up spending build time where it counts; elements that directly impact the quality of the product based on user’s real needs.
In other words, CDD can help you and your product team focus on what matters the most. Align these suggestions and feedback with our master roadmap and sprint cycle and you’ve got a killer feedback loop and product development strategy!
I can’t think of a better way to build consumer-centric products… if you have another way, please let me know so I can try it on for size! Otherwise, I’ll keep doing it this way.