Category: Entrepreneurship

One of the simplest, cheapest, and most effective user experience and product testing things you can do is with Skype screen sharing. It works so well because the person on the other end shares their screen, and with Skype you can’t take control of their desktop, so you can only watch what they do. The key is to ask them to accomplish tasks on a generic level (e.g. create a new blog post) and sit back and watch them work. You’ll be amazed at what you notice and value you gain from the questions they ask — they don’t have the same tunnel vision you do being so passionate about your application.

Here are some quick tips for user experience testing with Skype screen sharing:

• Don’t share your screen with them — make them share their screen and walk through things on their own while you watch
• Ask them to accomplish tasks and take at least 60 seconds after they get stuck before helping — them getting stuck and trying different options is great UI feedback
• Once you’ve had them go through different tasks, then take them through the product and go over the most important features describing the functionality — this is a cathartic exercise in that talking through it out loud with someone who hasn’t seen the app before helps you personally see new issues
• Do this with a new person on a weekly basis and then move to monthly as the product matures

One-way Skype screen sharing is the digital equivalent of one-mirrors for user testing — only it is free and significantly easier. My recommendation is for entrepreneurs and product managers to incorporate this into their product development process.

What else? What are some other tips for user experience testing with Skype screen sharing?

Two weeks ago I had separate conversations with different entrepreneurs about how they prioritize research and development in their companies. Each conversation was brought up independently but the respective entrepreneur lamented how as their companies had grown the speed with which new features were released slowed down — it was now hard to make time for R & D. Customers were requesting enhancements to existing features, the architecture team wanted to improve back-end items, and the support team wanted to make certain processes easier.

One entrepreneur was thinking of going to an 80/20 model where engineers spent 20% of their time on new features and 80% of their time on existing requests. The other entrepreneur was thinking of dividing the engineers up into different teams where one team would only be new features and the other team would working on existing functionality. There’s no easy answer.

Here are a few best practices when prioritizing time for new features:

• Continually re-iterate that every hour spent on a new feature is taking time away from some other change, and that that is OK
• Remind all stakeholders that you can’t make everyone happy but that by having a strong vision and opinion for the product you’ll minimize time spent on features that are too narrow in focus
• Work with sales, marketing, support, operations, and engineering along with soliciting input from customers and partners during the time allocation decision making process

Prioritizing time for new R & D relative to other requests is hard. The best thing to do is to make the necessary time, over communicate, and deliver great results.

What else? What other thoughts do you have on prioritizing time for new research and development?

We like to push out new features fast. Very fast. On a typical day we might push out four updates of our software to production. Now, we don’t do continuous deployment but I’d like it if we did. Do we make mistakes? Yes. The great thing about our mistakes is that they are small, because we push the changes out in bite-sized chunks. With small mistakes come small issues that we can fix quickly. The more complex the change the more complex the fix.

We do a combination of code reviews, human testing, unit testing, functional testing, and continuous end user experience monitoring. This doesn’t catch everything but it catches the vast majority of issues and always ensures the core system works. We find that customers prefer fast product innovation with minor hiccups to much slower product innovation, and still have minor hiccups. To err is human, and we’re comfortable with that.

My recommendation is to move fast and build that into the core competency of the business. Startups win by staying closest to the customer and moving fast.

What else? What do you think about pushing out features fast?

A friend of mine from college joined salesforce.com (yes, all lowercase is the proper spelling — it’s a late 90s dot com thing) right after he finished business school and has been there for several years. At last year’s Dreamforce conference I was asking him about their engineering department and how they structure on-shore/off-shore software development. He said all the R&D is done in San Francisco in a pod-like setup similar to yesterday’s post on pods at Rackspace.

Here’s some info on pods in R&D at salesforce.com:

• There are roughly 28 different teams/pods
• Each team focuses on a specific module or piece of a module in the product
• The pods have one product manager, roughly five engineers, and a QA person
• Each pod does a daily stand-up scrum meeting led by the product manager
• The large number of product managers allows each of the small teams to stay close to the customer and minimize the telephone game where details get lost in layers of bureaucracy

The pod approach makes it easy for salesforce.com to scale their R&D by adding more and more pods as the business grows while staying agile and innovating quickly.

What else? What do you think of the pod approach to scaling R&D?