I’m not sure if it’s an official term or not, but “collaborative development” is something we believe in strongly. Let me explain how it’s defined and how we at Shugo have it implemented.
Collaborative development is the process of including key stakeholders into the design and development process of new features. Most importantly, collaborative development pulls in the thoughts of existing users to ensure a feature’s intended result meet their needs.
Is it revolutionary? Absolutely not.
Do a number of organizations practice this? Sure.
Is it common or uncommon for software developers to ask for feedback from stakeholders during the design phase? My gut tells me it’s uncommon, at least in the industries that we participate in.
If you go and read about some of the breakthroughs from companies like Apple and Google, you’ll read stories about providing features and functionality that users don’t even know they need. Take the iPod for example.
Was the public screaming for a digital music device? No.
Did it revolutionize the way we listen to music? Absolutely.
Did Apple bring users into the design phase? Probably not since it was new (and I’m sure a top secret project).
But I’m willing to bet if you look at future iterations of the product, Apple took into account feedback from key stakeholders. It’s why we saw new generations of the product being released (besides the fact that a new version equals new revenue opportunities).
With our product lines, we rely on user feedback. We even pull stakeholders into the design phase. Obviously we can’t solicit opinions from all our users, but having some feedback early ensures we’re building functionality that our users want and need.
Now before I go on, let me share we don’t do this with all things we design and develop. Some of our product lines followed the initial iPod model I mentioned above. PUSH is a great example. No one was requesting text message alerts from payroll and I’ll admit, some to this day still have trouble fathoming it. But others instantly saw the value once we released it, both from a “sexy” sales and operational efficiency perspective.
HUB on the other hand was, and still is, the model of collaborative development. For over a year, a number of our clients had shared their desire for a more robust solution for employees they service than our current pay stub and W2 delivery system. They even outlined for us the intended features and functions their clients would need. In fact, one even wrote design specs for us.
Together, we created a solution that now services employees all across the country. Just this week we were designing a new feature to help reduce some support requests we receive. Rather than just building this feature blindly, we communicated with a few clients who initiated these support requests. This was invaluable as we learned of some additional scenarios they encounter. These scenarios covered a much broader spectrum than our initial feature intent.
Good thing we did this as we rethought our approach and now have designed a different solution with a much better result.
Collaborative development all sounds hunky dory but please don’t think it comes without some struggles. Let me share some of these so if you do adapt this policy:
- Stay focused on the task at hand: Being collaborative often times leads to a longer design period with a number of varying opinions (the old too many chefs in the kitchen cliche). Because of this, you must always stay in control. It’s great to hear opinions, but you must be able to stay focused on your task at hand.
- Learn how to say no: Let’s be honest, every opinion you receive is not going to be good but how do you say no to a customer who pays you money for your software? Simply, with two letters “N O”. It’s not wrong to say no. Obviously you don’t want to be arrogant but remember this is your product and you still need to ensure it’s still in your vision. So be polite and thank your clients for their feedback but just share that’s now how you envision it. After you do it once or twice, it’ll become much easier.