More Business Organics

A few weeks ago, I wrote a blog entitled Business Organics. Now, along comes a blog from Jason Freid at 37signals that compares software development cycles to the growth of plants.

Introducing 5Rules

Highly astute readers of this blog will notice that I've just added a new site link to a soon to be launched venture I'm involved in, called 5Rules.

5Rules is a software company that creates web applications to make everyday business processes simpler. We're targeting small to mid-sized companies with 10-100 employees, who don't have the internal I.T. resources, the money or the time to automate many of the processes they currently manage using paper forms and interoffice mail. (We aren't discriminating... big companies can use it too!)

Our model is to provide easy to use, web based applications. That means all you need is a PC and an internet connection to get started. (If you’re reading this, you’re already there!)

Our goal is to build great applications which adhere to 5Rules. (Hence the name.)

Rule 1. Quick start. You should be able to begin using our software in 5 minutes. No extensive training is required. All you need to get started is a PC connected to the internet!

Rule 2. Intuitive application design and functionality. Information, help and functions are laid out as you’d expect them. We will provide screen shots and demos to show you how easy it is! Information about each feature is embedded throughout the application (although we don't think you'll need it!)

Rule 3. Just what you need and nothing more. We are designing our apps to serve a single purpose and don’t overload them with features you’ll never use.

Rule 4. A Risk free experience. Try our applications for free. If you do subscribe to our more fully featured versions and decide to leave, you may do so at any time. And you can take your data with you. (We don’t take hostages!).

Rule 5. Provide Value for money. Our aim is to satisfy the needs of small to mid sized companies who can’t afford big software prices, so we price our applications to provide great value for what you get.

Our inspiration comes from the guys at 37signals, who are pioneers in the art of building terrific, well designed, easy to use web apps. And inspiration also comes from a lifetime in business, where many processes are still much more complicated and cumbersome than they need to be.

Our company site will be up in a couple of weeks, when we'll introduce our first application and start soliciting volunteers to help Beta test applications as soon as they're ready!

Maybe the Apple was Just Bruised

After reading Steve Jobs' open letter addressing the legions of upset iPhone customers, he may have turned a bad situation into a positive one.

After reading Digg comments to his open letter, he seems to have placated most of the mob.

Rotten Apple?

If you were one of the early iPhone adopters, you probably feel like these people after hearing the announcement of the $200 price cut.

What was Apple thinking?

Hundreds of thousands of people gladly shelled out $600 for the iPhones when they first arrived. They camped in line in front of Apple stores! The product was met with rave reviews. Customers absolutely believed they were getting value for their money.

Until Apple convinced them otherwise, with yesterday's announcement.

I could understand a SMALL price drop - or perhaps even some sort of pre-Christmas sale. But to chop the price by $200 within 66 days of launch? That thing is depreciating faster than my Ford Focus!

Makes one wonder how long the lines will be for the next new Apple product?

Step right up..... please?

The Power of Surveys

I'm a fan of surveys.

I've used surveys throughout my career to help me gauge helpdesk customer satisfaction, effectiveness of communications/training and sometimes to determine how well an I.T. project is going (from my customers' perspective). There are dozens of survey tools available, but typically I use Survey Monkey for its ease of use..

I only have a few rules about surveying.

1. Surveys should be made of not more than 8, clear, concise, unambiguous, well thought out questions.
2. Each survey should take less than 2 minutes to complete.
3. The survey results are always shared with my team and my customers, usually posted on a portal for everyone to see - whether good news or bad.
4. Most times, the last survey question is an open ended one. How can we improve? (the experience, process, training or communications).
5. I usually allow anonymous responses (I send out the invitations to specific invitees, but don't track the responses by individual). I really believe it allows for more open, honest feedback.

As long as you limit your surveys to important issues and don't spam your employees or customers, my experience is that most people will fill them out.

Sometimes you find out more than you bargained for.

We were conducting a post system implementation review and wanted to find out how our customers' "go live" experiences were. While I knew that many sites were struggling with the new system, I suspected that part of the reason was the (low) level of priority that local management had given to preparing for the project.

And so I did something a little sneaky.

I prepared one survey, but sent it to two distinct groups; Managers and End Users. The survey results for the two groups were pretty consistent until we reached a question about site readiness for the "go live".

While the majority of management thought their sites were well prepared, 85% of their employees felt they weren't! We identified a clear disconnect between site management perceptions and those of their staff.

Based upon the open ended question at the end of the survey, it was clear that the site management were not nearly engaged as they said they were. According to employee comments, managers rarely spoke about the importance of the project, never updated employees on progress and didn't allow adequate (or in some cases ANY) training practice time for the employees to get comfortable with the new system.

While we conducted site readiness assessments before we went live, we made the mistake of asking the managers only.

Lesson learned.

Why Should Anyone Be Led by You?

I just rediscovered this seven year old HBR article on Leadership, entitled "Why Should Anyone Be Led by You?" It's written by Robert Goffee and Gareth Jones who have authored a book by the same title.

The question is as relevant today as it was in 2000.

Have You Mashed Yet?

Back in April, I wrote a blog entitled 3 Experiments to Try Right Now. One of the suggestions was to experiment with mashups - the linking of multiple databases to create new integrated experiences.

As outlined in a New York Times article, experimenting with mashups is easier than ever.

If you haven't begun experimenting with mashups yet, look for an opportunity within your business and use it as a personal growth opportunity for one of your developers.

I'm betting that once you've mashed, you'll keep on mashing.