There was a myth that Israelis were not very good at creating consumer-facing products. Notwithstanding their creation of ICQ, Israelis were known as engineers and researchers who did well within the confines of a lab but not so well when reaching out to end consumers. Over the last couple of years, though, the high-tech industry in Israel has gone through dramatic changes.

The stars of the Israeli tech scene were once companies like Comverse and Amdocs. Now, we're seeing an influx of great Web 2.0 media and social startups, such as:

• FoxyTunes, the Firefox plugin that allows users to control iTunes directly from their browser, and which was acquired by Yahoo for a reported $30 million;
• MyHeritage , the world's largest family network, which has already documented over 330 million family members and is reportedly bringing in some of the highest revenue of any Israeli Web startup;
• Kaltura, an open-source platform for the creation and consumption of rich-media Web applications, whose clients include Wikipedia, Universal Studios, Coca-Cola, and Pepsi.

So, what's in store for Israel's startup world?

Israel succeeds by blending the old with the new. The country will continue to exploit its innate talent for research and development and continue to make inroads with social media applications, all the while sticking to intensive, customer-driven products.

A few Israeli newborns to keep your eyes on:

• SimilarWeb, an intelligent add-on that sits in your browser and provides easy access to websites with similar content;
• Boxee, a cross-platform freeware media center with social networking features and a 10-foot user interface design for the living-room TV;
• CamSpace, a new interface for computer games that uses innovative computer vision technology that allows everyone with a webcam to play games Wii-style;
• Vetrina's, a virtual window-shopping platform that transforms the online shopping experience.

The glue holding this generation of Israeli startups together is that while the companies are now all consumer- and media-related, they have a more technological edge than can be found in companies elsewhere. You can take the engineers out of the lab, but you can't take the lab out of the engineers.

Guest author Ayelet Noff is one of Israel's most renowned bloggers. She is also the founder and CEO of Blonde 2.0, a full consultancy firm whose mission is to help brands understand how to use social media tools (social networks, the blogosphere, and social software) effectively in order to carry their messages across the globe.

Now, there's a cost-effective means of seeing how usable your pages are: Userfly, a simple way to test your site's usability for free - with one line of code.

The user behavior is recorded for the entire site visit, following the user from page to page. Once the user leaves the site, the capture ends.

Reviewing the walkthroughs is just as easy. Userfly provides information on the user's browser, each page visited, and time spent on each page. Clicking on a particular page plays back the interaction, showing where the user moved his or her mouse and where he or she clicked. Once you're finished watching, you're prompted to rate the usefulness of the capture. Then, you can decide to keep it or discard it.

Even during a short test, I found Userfly incredibly helpful - given that a number of users stopped by as I was testing the app. In fact, the only complaint I had was that the walkthrough fails to automatically pan as the user scrolls. Meaning? Meaning you have to manually scroll to keep up with the mouse movements - which I found to be nearly impossible on lengthy posts.

When the user didn't scroll, however, I found myself replaying the walkthroughs over and over. It was invaluable to see how other users see and use the pages that I find so familiar. Suffice it to say, I immediately noticed areas for improvement.

Userfly will allow you to record 10 users per hour, monitoring basic events for free. Those who are interested in more users per hour and more advanced events can contact Userfly for a quote.

How are people using your site? Wouldn't you like to know? Grab the code at Userfly and take a look at your site through someone else's eyes.

Larger software companies possess complex bug and issue tracking systems to help them capture, triage, and respond to this type of feedback, but smaller companies often still struggle to find a way of managing this information. Sifter hopes to change that with a simple and straightforward bug and issue tracking app.

Admittedly, a number of products have attempted to solve this tracking problem, simple or otherwise. What makes Sifter different? Sifter is built in the "less is more" vein of product development. There's just enough there, but not too much.

When I saw Sifter, I immediately thought of it as the perfect complement to Get Satisfaction. Get Satisfaction makes gathering customer feedback incredibly simple. And Sifter proposes to make dealing with that feedback just as simple. What's more, Sifter is so straightforward that practically anyone - not just developers used to issue tracking systems - can use it. And that has the potential of making every person on the team a valuable contributor to the system.

But there's something else happening here. Thanks to its simplicity, Sifter actually makes bug and issue tracking accessible to groups who may have never considered it before: Web developers, blogging teams, community managers, graphic designers, and the like.

When it comes right down to it, tracking issues shouldn't be terribly complex. There's a problem that needs to be solved. And someone needs to solve it. Unfortunately, that apparent simplicity leads many smaller teams to forego the cost of a traditional management system by using email or spreadsheets to manage the incoming requests and assignments. Then things begin to fall through the cracks.

Yes, tracking should be a simple process. But there still needs to be process. Sifter seems to understand this. And they've priced their solution accordingly.

In terms of product development, Sifter has something else that makes it interesting. Sifter's whole development history was transparent. So you can go back to see why decisions were made. And get an idea of what might be coming next.

If you're part of a small team of developers who find typical bug tracking software too arduous or don't want to deal with having to set up a service of your own - or if you're someone who deals with issues but has never considered a bug tracking system to manage them - Sifter may be for you.

Use of hosted software as a service (SaaS) is growing like crazy, and most products are constantly evolving. What is the best strategy for a tech startup: share its product road map (i.e. its development plans) with the outside world, or keep its cards close to the chest?

Mike McDerment from FreshBooks argues very convincingly for keeping it to yourself:

1. Commitments weigh you down (if you promise something and change your mind later)
2. Keep your competition guessing
3. Purchasing decisions get delayed (as people wait for the next great version)
4. Don't set expectations too high
5. You can bank on surprise and delight

I feel strongly that sharing your product road map to gain (and actually use) feedback from your clients is the best product strategy for any rapidly evolving software company.

We have always been fans of the "Agile" development methodology, and when we embarked on developing Wild Apricot back in early 2006, there was no doubt in our mind how to go about it. Instead of trying to design and develop a "perfect" product (which would probably take a year or more), we created a list of "user stories" (product features) and prioritized them according to what we could do in 3 months.

Wild Apricot aims to simplify life for people in associations and non-profits. It replaces five separate pieces of software with one, saving thousands of dollars and countless hours of data re-entry and reconciliation. It automates trivial administration tasks and lets people focus on their cause and passion.

Our first beta release was launched on June 30th, 2006. Feedback started to trickle in right away, and as we started to count accounts in the dozens and then hundreds and then thousands, it really poured in (and keeps pouring!).

Our initial road map was around 80 entries. Our current list is over 400 items, and the cycle never ends:

• Release an update
• Review accumulated feedback from clients, and add or change items in the work queue
• Reprioritize the new list, and pick top items we can fit into our next update
• Several weeks of intensive development, then testing
• Rinse and repeat

(We currently issue product updates every 6 to 7 weeks on average.)

One curious fact is that half of the items on our original list have not been completed, while we have released a couple of hundred other items that our clients requested from us.

This is the ultimate reason behind this strategy: our own team is smart, but the accumulated wisdom of our clients makes our product development much smarter than it would be if we did it on our own.

Let me circle back to Mike McDerment's points:

Yes, that's why you have to be very careful about what commitments you make, and about sticking to them. We made our share of mistakes: promising that "This feature would be released in a few months," and having clients ridicule us for still not having released it after 18 months.

Here is the process we follow:

We maintain a special discussion forum (a wish list): any client can register and post their ideas, or comment and vote on ideas provided by others. Our support team encourages and directs all clients to join the conversation there.

Our product management team constantly monitors this forum and participates and guides the discussion. After each product release, we conduct a thorough review of the wish list. One frequently voiced criticism of using client feedback to guide your research and development is that all of those ideas are too tactical and are not innovative; the fax machine would never have been invented in this fashion, by just collecting feedback for the good old postal service. My answer is that this is where our team adds the most value. Our job is not simply to take one suggestion after another, but instead to look for patterns and commonality and then generate innovative ideas and features that address the feedback, even though it may be in a totally different way than envisioned by the original client.

As an outcome of that, we regularly update the road map discussion forum, which contains the top 60 items that we consider to be pretty well defined and ready to be queued for detailed analysis and development. We do not allow clients to create new entries in this forum, but they can freely comment and rank threads that we have created.

This list of items forms the core of our work queue, which is reviewed and prioritized for each release. Again, the priority assigned to each item is based mainly on its ranking and comments by clients; but here we also have to weigh those rankings and comments against architectural considerations and the long-term vision for the system.

And of course we have to work a number of "unsexy" items into each release to maintain system and data security, ensure reliability, improve system speed, and deal with bugs.

Finally, the feedback loop closes with our weekly product update posts on our blog.

To address the other points Mike brought up:

For us, the competitive edge is in the execution, not the initial ideas, which are a dime a dozen. Plus, of course, customer service, however lame it might sound: this old-fashioned concept still goes a long way towards winning (and losing) clients.

Because we have this regular rhythm of new releases, people sign up at a steady pace, and the next update is always around the corner anyway. And if somebody needs a particular feature we do not have yet, I would rather have them wait and get more experience down the road than waste too much time shouting "SIGN UP NOW! SPECIAL OFFER ENDS TODAY!"

I say, set them high and deliver on your promises.

But you lose out on anticipation (also see Andy's point #2 below).

Let me close by quoting Andy Sernovitz, author of Word of Mouth Marketing (a must-read book, by the way, for any technology marketer: lots of practical advice). He also thinks that product road maps should be shared and makes these points:

1. Users will be thrilled to know how the product is going to improve.
2. You turn frustration into anticipation.
3. Your fans have something to talk about (more word of mouth!).

To close, I do not think there is a single strategy that works for every company and every team. Freshbooks is a very successful company, and we are looking to them in many respects. Our crowd-sourcing strategy works well for us and is a good fit for our team and product. The journey continues. Check out our release history.

What is your experience with crowdsourcing? Any thoughts on product road maps for software companies?

If you're a non-profit organization wanting to use the Web more effectively, try out the Wild Apricot suite of products and support a RWW sponsor.