Characteristics of your early adopters to tech projects

Apple Store, University Avenue, Palo Alto, CA

Image via Wikipedia

We all have seen the news stories of the line around the Apple store when iPhone was released and then again when iPad was released. It’s pretty clear to see that those customers outside that store are the early adopters of Apple’s technology. They are completely invested in trying the new tool out and they willingly go forth knowing that first generation usually will have some blips and beeps that aren’t exactly right.

So when you are facing a new project, what qualities or characteristics do you need to see in the people around you to know that they are your early adopters? For me, I have found that often what I need in an early adopter of a tech project is not always the same person who is standing outside of Apple waiting to have a new iPhone or iPad in their hands. Sometimes, I have found that those Apple early adopters are amongst the most difficult people to get on board with my tech project.

I’ve noted a few characteristics and I really hope that this drives some conversation, because early adopters are the life blood of almost any tech project. I’m always looking for new ways to convert over more to this category and I might not see something as a sign of being this type of person – but you might. Let me know what other characteristics you would include on this list.

  • Leadership – There are two things I must mention under leadership – I need both types – the leaders with official power and the leaders without official power. Most tech projects do not get launched if there is not a member of upper management who has given their blessing. If I can’t get that leader to bless the ‘go forth’ movement, I have to go above them – to the board tech committee. That is very rare now. But the more important leader you need to get into the early adopter category is the unofficial leader. This is the person that others might go to for help because they are afraid of tech staff. This is the person who you know if they discount the project that their word will care far more harm. I find most of my time is spent with these types of leaders – but no doubt about it – you need both leaders.
  • Ability to give constructive feedback – There are some people who are going to find every single thing wrong with a project. If it is a database project, they are going to hate the font, color, logo, and even the pace of the cursor blinking speed. This person is just providing criticism – not truly useful feedback. Constructive feedback never feels like an attack and it provides more information. Maybe the issue with the font is a true issue. The person providing constructive feedback would indicate that the font is an issue and then provide examples about why it is an issue. That why is so important! For more about constructive feedback, read The 4-1-1- on Constructive Criticism.
  • Independence – Counting on the scope of your project, you may not have a lot of time to provide one-on-one training. Early adopters are more than happy to explore on their own. In fact, they often prefer to be given a little bit of information and go off on their own. While this can be scary (they might run into something that isn’t done!), it is so useful for you. Your time can be spent on preparing for those other users who need more guidance and assistance.
  • Sees the ‘light at the end of the tunnel’ – Again, your type of project impacts how important this is. Switching out hardware probably won’t be hard to sell the end of the project. But if you are in a project with lots of twists and turns (database development is my example here again), you need to have someone who can see that after a lot of work up front, the work will be less at the end. Too many people get hung up with how much ‘extra’ work there is at the beginning of a project. Their fears get in the way as they begin to fear that it will always be all this extra work to make it happen. Your early adopter needs to be invested in your vision of the end of the project. They then become your voice with others when you start pushing the project out to others.
  • Ability to market the project – You are not the best person to sell your project to other end users.  Your early adopter is the best person to sell your project. These early adopters should be able to communicate either verbally or written the positive points of the project. They will tie in the ‘light at the end of the tunnel’ vision along with benefits they have found. Your early adopters are going to find benefits that you haven’t even thought of – and they should be able to tell others about it. They need to be able to talk to you, of course – but more importantly, you need them talking to others.
  • Not always tech savvy – While I would want users who are a bit more tech savvy if I was working on a completely mobile solution, I know the big kudos that can be gained if you get that person who isn’t as comfortable with technology involved in your project. Often users don’t believe me when I saw that I’m targeting the project for the non-technical comfortable person more than the ones who may have been out buying an iPhone or an iPad that first day. Truly, projects fail if you aren’t able to address that user who struggles with figuring out the power button. If you can get someone like in as an early adopter, you are tapping into a valuable resource that in the long run will make the project more successful.

Early adopters are so important that I plan on spending more time on this topic. It has been a very vital part of my job of late and I know as a nonprofit techie I cannot always find enough tips on how to find, manage, assist, encourage, develop and maintain these early adopters. They make the projects successful.

When the Fuzzy Front End Reappears – Beware!


It would be nice if projects were as easy to manage as a teddy bear. Image by estherase via Flickr

I will honestly admit, I didn’t know what was meant by the fuzzy front end until I was looking for some resources about keeping custom application development on track. I had heard about the agile methodology and the scrum methodology, but I hadn’t heard the phrase the “fuzzy front end” until recently. Part of the reason I’m sharing this is because I’ve been in a situation where some of the tenants of what marks the fuzzy front end have reemerged towards the end of a project that I’m working on. It’s really scary because the fuzzy front end should really be the beginning of a project.

For those involved with innovation, the fuzzy front end is that odd period of time at the very beginning of a project when you know that you have to do something and you are gathering all the requirements and desires about the project, prior to developing a project. What is interesting to me is that in the articles I have been reading about the fuzzy front end, almost all point out that the key activities that go on in the fuzzy front end are not always the same. More importantly, even within the same organization, this period of time does not happen with the same steps.

Now, I’ve been in a project for a long time and I’m seeing a lot of the things that we were seeking answers for at the beginning of the project, occurring again right before we are ready to wrap up the project. After spending so much time trying to prepare for what was needed, a new wealth of ideas, concerns, and requests are flooding in. In reading material by Johan Frishammar and Henrik Floren titled “Achieving Success in the Fuzzy Front End Phase of Innovation“, they outlined 17 success factors. I’m well beyond the fuzzy front end, but I am finding out that several of their success factors are really good strategies to combat this second wave of input that feels a lot like I’m at the beginning again.

  • The presence of idea visionaries or product champions – This success strategy that Frishammar and Floren outlined really harkens back to a person or persons who are forward thinking and can think of the large picture. I have found that a lot of the reasons why we are struggling to complete and we are re-evaluating stuff that was done years ago, is because the focus was now on the nitty-gritty details, and not the overall picture. I’m too in the trenches right now to be seen as the idea visionary or champion – so I had to bring in someone else to be that person – our CEO. The entire team had a discussion on the history of the project and how it is to fit into the bigger picture. It was a nice shot in the arm for some.
  • An adequate degree of formalization – I haven’t heard too many stories of other nonprofits being really rigid in their structure, but I know that formalization varies from agency to agency. I tend to believe that I’m in an organization that is pretty darn flexible. While that is great for almost everything we do, it also makes project management difficult. As this project has had bumps in the road, we’ve had to put more formal methods of documenting what is going on into place. If this was done at the very beginning, and assignments given, it wouldn’t be seem as a band-aid  for the situation. But now that we have identified the struggles we have had, putting in a structure has helped out. It is perfect to know that you are sending out minutes of meetings outlining decisions that were made. It gives a formal outline of what was done and tangible proof of agreements.
  • Project management and the presence of a project manager – It was hinted to in the last step that I identified. Now, I cannot stress how vital it is for someone to play this role. If you are struggling with a project and no one has really stepped up to be the leader in coordinating efforts, take the time to either identify the project manager, or take the lead yourself and be the project manager. It might mean more time on your side, but the group will gain traction and start moving forward again with just this simple change.
  • Beneficial external cooperation with others actors – I believe that the agile methodology and the scrum methodology shows how a team can move forward a project in development. But if you are having new ideas or requirements arriving at the table, late in the game, it can be harmful. I believe that you are never going to build a project that satisfies every single persons need, but when new people are inserted into your group, if they know nothing, someone has to give them the guided tour. Someone has to educate the new member to where you are and how you are operating. If you get too many new members, your entire group changes and adjustments have to be made. I wish I could include every bell and whistle that is desired by every user, but it isn’t possible. What’s important is to get the most important and critical items, and know that it isn’t all going to happen.
  • Project priorities – This success step can be awfully difficult to address if you are in a project that crosses between multiple departments. I like to compare this to when upgrading to a new version of Microsoft Office. There are some departments that the biggest concern is how different is Outlook. There are other departments that are more concerned if Word operates better. Of course you then have the accounting department that is all about Excel. When you have a mixed team working together on a project, each member is probably going to have a different priority. If you have to stop forward progress and identify what are the priorities of this project overall, then stop and do that. It gets everyone back on the same page and you combat the feeling that you are heading back to the Fuzzy Front End.

I know that this is a process and also realize that while we near the end of this particular project, we are also nearing the beginning of the fuzzy front end again. It happens when you start mentioning “phase two” or “next version”. These aren’t bad things.  But it can be a game changer if you cannot find a way to identify these items for this next cycle and find a way to close the project that you are on right now.

I’m finding the reading about the fuzzy front end interesting and exciting. I want to learn a lot more about it because I know that as a nonprofit techie, I am going to really be involved with it more in the future.