An idea to implement R&D in a software services startup

This may be obvious (to echo @Jeff Oresik's comment), but why would you need to tell your clients that your developers spend 2-3 hours a week on R&D?

Assuming it's a small shop, you're probably handling a lot of overhead by yourself already (accounting, taxes, office concerns if you have one, etc.) If you met with your accountant on a Friday morning for 3 hours, do your clients really care to know that?

One other idea: treat the R&D projects exactly as you would a client project. That means making the R&D time billable (to you, however), which means developers submitting invoices, and an emphasis on tangible/useful results. You'd have to do this anyway for tax purposes, if applicable. Have developers come up with estimates for projects. This process means the R&D projects that are proposed are given more thought to how they will be useful, and with concrete goals and an end game.

Personally, that setup wouldn't stymie my creativity for R&D, but some might complain the "process" would. If you want it to be more like actual downtime, then explicitly make it so. Set a 37hr week policy, and increase developers' rates/pay to match what they were getting under 40hrs.

...if its a good thing to implement this idea in a startup where finances are client-driven?

I think it's an excellent idea (if implemented correctly). This is a great way to not only attract good quality programmers, but also to hold onto your existing employees. Employee morale and motivation is a huge factor in your company's success. 2-3 hours a week is not a whole lot (assuming a 40 hr week), and shouldn't impact your bottomline all that much.

How do you convey this message to the client (that for so-and-so time period, we won't be addressing your concerns)?

You don't. Your clients don't expect you to be working on their project 24/7. They know they are not your only client, and that your programmers must split their time among all the projects. Your clients don't expect you to tell them: "We will work on your project from 8:00am to 11:00am on Monday." The only thing you need to tell them is that "this project will take X amount of hours to complete, and will be completed by Nov 15, 2010." How it gets completed in that timeframe is not their concern.

how would you feel is the best way to go about it?

1. I would recommend that you don't make all of your programmers spend their 2-3 hours at the same time. They should schedule their research time at different times during the week, so that you are always working on a paying project at all times, versus stopping all work at any given time.

2. Also, don't schedule the time for them. Let them manage that themselves. If you tell Bob that his research time will only be on Thursdays from 9am to 11am, you can be sure that Bob will stop whatever it is that he is doing at 9am on Thursdays. If Bob is being really productive at that time and is on a roll, it would be bad to interrupt that. Let Bob fit in his research time during his downtime or when he needs a break from his programming tasks.

3. Make sure you include something in your employee contract about this. Any IP created during this time belongs to the company, not the employee.

There are many examples of company transition from a service company to a product company, 37signals being one of the most famous one.

Doing client work can be not very fulfilling -- you have to do what your client asks and usually this doesn't envolve playing with the latest cool piece of technology. That's understandable.

You want to talk with your peers what your ultimate goal is. If you want to build a product company that's fine. You can start with one or two guys, try different things and see if something gets traction. Just articulate clearly that time spent on "researching product ideas" is an investment -- it's time not spent on client work (non-billable) and you might never recover it.