Lately I've been having a lot of ALM conversations, based around process and how to be a better developer. And one of the things I hear a lot is belly-aching. Which honestly isn't that surprising. As developers I believe it is engrained in our DNA to want to solve problems. We are doers, and we push to get into code as fast as possible and start solving problems immediately.

Let me start by saying that this is a great instinct to have, and it will help you build a fantastic career in this field. It's that I sometimes have to fight back, as we love to play with shiny new technologies and leverage them to do amazing things.

But where a lot of developers fail is that they feel, if I build this amazing system, that will change the world. That's it, I've done my part. Sign my Zuckerberg level check, and I'll be on my way.

The part that's missing her is getting people to use your application. And that's the part that many of us just don't want to talk about. We don't want to discuss marketing, or branding, or value propositions. Because at the end of the day that's not something we enjoy. We built it, and they should recognize our genius. Unfortunately that's just not how the world works.

At the end of the day, this part is just as important as the coding to support this project. And that's to not only drive usage of your software but a cultural change within your organization. You can't do that alone, but it also will fail outright without your support. There is a great book I recommend for everyone called Raving Fans, which talks about having a loyal customer just means that the friction required to change to someone else is high enough to make them be lazy about it. What you want are raving fans, people who will go out of their way to leverage your services, and its this philosophy that will drive people to be customers who seek out your solutions.

So the question becomes, how can I get people to use the software I created and see the value I know it has. To me I've come up with an easy way to remember this…SMACK them with it. The SMACK acronym is designed to help you know key points you should keep in mind when you are trying to drive that adoption of your solution.

1.) Speak their languages.

At the end of the day, these are not technical people and you need to understand that. They don't want to hear about your architectural diagrams, and they don't want to talk about the patterns you implemented. What they do want to talk about is value, and how it aligns to their goals and mission. So skip the tech jargon, and speak in impact, dollars and sense or productivity. The approach I always use here is, assume they believe you can do everything you say. What else would you talk about?

2.) Make sure it's easy to use.

Look at many of the most heavily used applications in the world. Facebook, Amazon, Gmail, Outlook.com. They all have one thing in common, the UI is simple and intuitive. You can't spend too much time on UI and user experience. These are things that users do care about. And its another reason I support technologies like entity framework. Anything that takes the developers attention off plumbing code and focuses it on the user experience. This is what matters the most.

3.) Accept feedback

This item I find many a developer has a problem with. We all work really hard on these applications, and when users question or even criticize elements of it, we take it personally. Someone is calling our baby ugly. But at the end of the day, this feedback should be taken as a gift. Any user feedback can be helpful, especially when aggregated. In my opinion, aggregated feedback makes this infinitely easier as the identification of trends can make the bitter pill easier to swallow. Its not one user saying your baby is ugly, its general consensus.

4.) Champions are essential:

Nothing helps drive adoption like a champion. Someone who can relate to your users and talk to the benefits of the app is worth its weight in gold. You can say the exact same things that they do, but until they hear it from a user who shares their pain, or someone in a position of authority, you might as well be a Peanuts teacher.

5.) Know what they care about.

Finally this goes again to the UI of the app, know what they care about in the app. Focus your time on functionality that matters and on delivering value to the user and they will intern become champions and preach to the world how great your work is.

This blog post is a high level post, and is going to be the start of a series, as I write a blog post about each of the 5 SMACK items listed above in greater details. Specifically looking at how this works in an Agile, Dev Ops, kind of world.