DPO Design Board in the War Room
As Director of Product Development and Delivery for SofterWare, my number one goal is to get great-working, elegant solutions in front of you. My team is responsible for putting “keys-to-code” as well call it – writing software code, fixing bugs, testing solutions, and designing the enhancements that actually end up in our products. Sometimes it’s a daunting challenge, and we’re never short of things to work on. Our product managers are constantly on the lookout for new and interesting improvements. We get great suggestions and wish list items through our “Suggest & Vote” application – which lets you submit ideas and vote on those submitted by other organizations. Our Client Advisory Board gives us great feedback on how they use our products and what they need. Our sales team meets with prospective clients and gives us their take on where they see the industry headed. And of course we have a huge backlog of things we “just never got to do”… sometimes the list seems like it never ends.
So how do we actually decide what goes into our products? Well, as they say about sausages and legislation… sometimes you don’t want to see how it’s made.
Once or twice a month, we gather representatives from all over the company: Sales, Support, Client Relations, Development, Executives, and Product Managers. We get into a room, armed to the teeth with pitchforks, torches, shields, and arrows – and hash it out. (Well, maybe it just feels like a medieval battle). We review dozens of new and existing ideas – large and small, because sometimes it’s those “small” things that really enrich your experience. We prioritize and reprioritize – shuffle up and defer back. Look at effort and try to see impact. And it’s really, really hard. Every
idea has merit. Every
idea benefits somebody. Sometimes it gets heated… even passionate. But after an hour or so of vigorous debating, lobbying, proposing, and negotiating – all in your name as clients – we manage to come out with a plan for the next month. 30 days (or less) later, we do it all over again. If you feel your ears burning, it’s because we’re talking about you.
The fact is we usually have more work than we can ever get done. So how do we decide what to do first? Well, it’s not an exact process, but we certainly have some guidelines that we use to help decide. Questions like:
- “Will this benefit most of our customers – existing and new?” That’s an easy one. The fact is, the more customers we can make happy, the more we want to do it. An idea that will be used a lot, that benefits everybody, and has that “of-course-we-should-do-that” factor usually has no problem getting approved.
- “Great idea – but is there a way to do it in the product today?” That one’s a little harder. We’d love to put in every idea, but if a good method to do the same thing already exists in the product as it is, sometimes we have to choose to work on something else that’s more critical.
- “Can’t we just change it to make it simpler? “ – Sometimes there are things in our product that have been that way for so long that changing them would impact lots of our customers. For example, moving email addresses to their own table to provide unlimited emails might seem like a great idea, but it might also break our customer’s custom reports. Rearranging screens a different way might make great sense to a new client, but might cause existing clients to have to retrain their staff. We take changes to the product very seriously and want to be sure our clients have time to prepare for them.
- “I use DonorPerfect a little differently; can’t you just make this one change for me?” – Another really tough one. We strive to make our products as easy to use and as flexible as possible – and I never cease to be amazed at how clever our customers can be in using our products. It makes sense that they’d want to tailor it to their specific needs. But writing “custom code” for one client has an impact on every user that uses the product. It adds bloat and complexity to the code, which affects performance for everyone. It adds overhead for more testing to ensure that it doesn’t break in the future. And it diverts our staff from working on changes that benefit all of our customers.
- “This seems like it’s been this way forever. Why can’t we just fix this?” Ouch. Those are the hardest ones of all. Sometimes a bug only shows up for a specific client or under a particularly unusual set of circumstances – like a certain set of data or a certain version of a browser. Believe us when we say it kills us NOT to fix these items as soon as we hear about them, but sometimes reproducing them becomes a challenge, or fixing them would introduce a risk to the rest of our client base.
Of course, this doesn’t mean we only work on items reported by lots of clients. The fact is we make changes requested by single clients all the time. The challenge is in reviewing each client’s issue, needs and circumstances, and trying to make the best decision we can. In the last year we’ve implemented over 1400 enhancements in DonorPerfect alone –and many of them directly from clients! In reality, we’d love nothing more than to deliver 100% of the items in our backlog – and given enough time hopefully we will. But in the meantime, month in and month out, we do the best we to delight as many folks as possible, and create the best product in the industry for our clients.
In my next post I’m going to talk about a concept called “Agile Development” – that gets new ideas and enhancements out to you faster so we can get your feedback earlier. Let us know your thoughts in the feedback area.
Are Your Ears Burning?